Extrait d'un rapport original (by JCB)
La phase de conception représenta une part importante de notre travail sur les trois premiers mois du projet. Je présente ici les multiples étapes de cette phase et les pratiques spécifiques auxquelles nous avons eu recours pour concevoir le tutoriel et le dispositif de formation dans lequel il devait s’intégrer. Hormis un certain manque d’information, nous rencontrâmes finalement peu de problèmes pour accomplir notre travail que nous accomplîmes en toute indépendance vis à vis des services du ClientEntreprise.
Nécessité d’un schéma synthétique de notre intervention.
La planification générale des étapes de la conception fut définie en amont de l’étude des besoins et inscrite dans la convention d’étude. A la signature de celle-ci, nous ne savions pas avec certitude si le ClientEntreprise donnerait suite à notre étude et entamerait la mise en oeuvre effective du projet de formation. Il fut par conséquent nécessaire de délimiter notre champ d’intervention en matière d’étude et de conception. Etant donné que notre commanditaire n’avait qu’une perception très imprécise de ce que nous étions en mesure de réaliser, je décidai de joindre un schéma synthétique de notre mission, reprenant ses principales étapes et la nature des résultats auxquels nous aboutirions. Ce schéma mettait en évidence que, l’audit et une partie de la conception allaient se dérouler concomitamment. Il distinguait trois phases : L’élaboration du profil-métier, et celle du plan de formation propre au projet CRISTAL. La construction du dispositif de formation à mettre en oeuvre au lancement du projet. La définition du pré-concept du support E.A.O.
Le schéma illustrait aussi leur succession et les enchaînements possibles entre les étapes, de sorte que notre commanditaire disposait d’un plan d’action auquel il pouvait se référer à tout moment pour situer l’avancement de nos travaux. S’il le souhaitait, il pouvait anticiper sur notre action et s’assurer de la disponibilité de ses services en leur communiquant la date probable des échéances communes. Nous disposions ainsi d’une base de dialogue et de suivi, qui facilitait nos échanges lorsque nous le rencontrions.
Dans l’ensemble, j’estime que ce schéma synthétique fut très utile et satisfit au besoin que nous avions de faire comprendre à notre commanditaire la façon dont nous allions mener notre mission. Ce dernier était familiarisé, de part sa fonction, avec les représentation algorithmiques et n’eut aucune peine à percevoir la logique de notre action. En revanche, comme je l’ai déjà évoqué, la situation fut toute autre avec son service informatique, et notamment le C.P.I (chargé de la formation). Notre commanditaire ne souhaitant pas que son chef de projet prenne connaissance des clauses de la convention d’étude qui nous liait au ClientEntreprise, il exigea de nous que nous ne lui en communiquions ni le contenu ni la teneur ; ce que nous fîmes. Je suppose qu’une partie des dysfonctionnements qui intervinrent dans la coordination de nos actions en rapport avec ce service sont en partie dues à cette méconnaissance. Le C.P.I ne pouvait pas à son tour anticiper le déroulement de notre intervention et s’organiser en conséquence, ou plus exactement, en prévision.
Le profil-métier fut décliné en termes de fonction, mission, activités principales et spécifiques, tâches. Dans un premier temps, nous avions volontairement exclu de notre analyse les activités et tâches appartenant aux domaines suivants : Encadrement, stratégie et action commerciale, stratégie et action marketing, ressources humaines, communication interne et externe ; tel que nous l’avait laissé supposer la description du logiciel par notre commanditaire lors de l’établissement de la banque de propositions.
Cependant, nous nous sommes aperçus, une fois que nous fûmes en possession de ZeLogiciel, que certaines des activités de ces domaines impliquaient son utilisation. Aussi, bien qu’elles fussent écartées de notre investigation par l’une des clauses de la convention, nous consentîmes à les porter au profil-métier.
Méthode d’étude et d’élaboration du profil-métier.
Je rencontrai quelques difficultés à employer ma méthode dans le contexte du projet du ClientEntreprise. D’abord, parce qu’il m’était impossible d’auditer un échantillon du publi-cible et de recueillir auprès de lui de précieuses informations sur son métier. Ensuite parce que les adaptations que j’y apportais pour compenser cette carence en compliquaient la mise en oeuvre.
Mes seules sources d’information attitrées à cet instant de l’étude étaient le D.S.I, le C.P.I, et une abondante documentation (qui ne me fut d’aucune aide pour ce travail). Ces interlocuteurs furent en mesure de me fournir une description organisationnelle du métier ; c’est à dire celle d’un hiérarchique ne pratiquant pas le métier au quotidien, et ayant de ce dernier une vision plus théorique que pratique. De plus, cette description s’avérait insuffisante et je ne pouvais m’en contenter sans prendre le risque de perdre la maîtrise de cette phase d’étude. Par conséquent, je décidai d’avoir recours au ROME pour tenter de compléter mon information et d’adapter la méthode : il s’agissait de partir des emploi-métiers connexes et d’inférer vers celui de Central. Quant à la description fonctionnelle manquante, j’escomptai en obtenir une partie en me basant sur les fonctionnalités de l’outil informatique et de ZeLogiciel 5.
Cependant, ce détour méthodologique occasionna quelques complications dues au fait que le ROME convenait mal à ce genre d’étude. En effet il est essentiellement conçu pour mettre en évidence les aires de mobilité professionnelles ; les compétences y sont listées sans indication autre, que leur caractère commun ou spécifique. Ainsi, aucune hiérarchie ni ordonnancement fonctionnel n’y apparaît ; on y retrouve donc, sans distinction, aussi bien des missions que des activités et des tâches (eu égard à ma propre méthode).
Evidemment, il eut été préférable d’auditer un échantillon du publi-cible, ce qui nous aurait sûrement conduits à un meilleur résultat. Mais notre commanditaire ne souhaitait pas organiser une série de rencontres ; peut-être considérait-il que notre statut de consultants extérieurs ne se prêtait pas à ce genre d’intervention auprès du réseau en début d’étude.
Nous délimitâmes avec précision le cadre de la formation des Centraux, et précisâmes les domaines de formation dans lesquels le niveau des connaissances nécessitait d’être relevé. Les domaines à privilégier concernaient la gestion courante du commerce d’un Central : gestion commerciale, gestion administrative, comptabilité générale, juridique et fiscal ; et l’utilisation du nouveau système informatique : fonctionnalités et objectifs, manipulations fonctionnelles, utilisations courantes et spécifiques. Il s’ensuivit une définition exhaustive des savoirs requis.
Pour chaque thème, le niveau de connaissance souhaité apparaissait ainsi que son " équivalent contenu ". Afin de distinguer les connaissances prioritaires des connaissances secondaires, et par extension déduire le niveau de connaissance souhaité, nous partîmes des responsabilités professionnelles du Central en exercice : responsabilités juridiques, commerciales et financières. Toutes les connaissances se rapportant directement à l’une de ces responsabilités furent classées dans la catégorie prioritaire, dont les niveaux allaient de pratique courante à maîtrise. Les autres furent classées dans la catégorie secondaire comprenant les niveaux sensibilisation et pratique basique. Cette classification nous permit de déterminer le niveau d’approfondissement des contenus du plan de formation.
Nous rédigeâmes le plan de formation sous la forme d’un document récapitulatif complet et directement exploitable. Il reprenait l’ensemble des contenus de formation et les regroupait au sein de modules, structurés de façon didactique. L’organisation modulaire devait favoriser la création future des supports ; notamment le support E.A.O lors de la phase de scénarisation pédagogique.
Nous ne rencontrâmes aucun problème particulier lors de ces étapes. Nous disposions de toutes les données dont nous avions besoin, et il n’était pas nécessaire de faire appel à nos interlocuteurs du ClientEntreprise. Comme nous étions familiers des domaines de formation, il nous fut aisé de repérer et d’organiser les contenus qui découlaient du profil-métier. Quelques jours durant, nous travaillâmes dans la quiétude, partageant l’agréable sentiment de maîtriser notre projet.
Le dispositif global de formation visait à optimiser l’efficacité du projet de formation des centraux. Il devait garantir la bonne cohérence et l’équilibre général indispensables à la réussite de l’intégration de l’ E.A.O. Il fournissait une liste prévisionnelle des actions à mener auprès des acteurs concernés, qu’ils y interviennent directement ou indirectement, et auprès du public cible. Il prévoyait les mesures d’intégration nécessaires avant le début de la formation effective des Centraux et pendant celle-ci : information des acteurs concernés et intervenants, formation des formateurs, accompagnement et suivi des formateurs et intervenants directs, concertation des formateurs et intervenants, pilotage du dispositif, information du public cible, formation du public cible, accompagnement et suivi du public cible. Il s’ensuivait la validation de nos propositions, et si besoin la révision de certaines.
Nous rencontrâmes des difficultés lors de ces deux étapes. Il nous fut impossible de rencontrer l’équipe des formateurs en temps voulu - la rencontre avec ces derniers fut différée de 4 semaines - et les informations nous manquèrent pour concevoir entièrement le dispositif. Je pense que nous aurions pu rencontrer cette équipe au bon moment, et ne pas connaître ce retard, si nous avions abordé davantage le thème de la disponibilité de tous les acteurs lors de l’établissement de la banque de propositions. Faute de quoi nous dûmes échafauder des propositions incomplètes dont nous n’étions qu’à moitié sûrs. Il fut néanmoins décidé avec notre commanditaire de valider celles qui paraissaient les plus fiables et allaient dans le sens de ses desiderata. Un des critères principaux de validation fut le critère économique ; nous retînmes un ensemble de propositions cohérentes dont le coût total de mise en oeuvre correspondait au budget affecté au projet de formation. Dans les conditions du moment, je ne pense pas que nous eussions pu procéder différemment sans prendre le risque de rigidifier notre relation avec notre commanditaire, d’autant qu’il s’estimait satisfait de notre prestation. Nous choisîmes simplement de l’avertir de la mauvaise lisibilité dont nous disposions, de lui présenter les propositions les plus raisonnables et de nous en remettre à ses choix en veillant à ce qu’ils fussent cohérents.
Le dispositif de formation organisait les propositions retenues et listait les mesures d’intégration précoces de l’ E.A.O à mettre en oeuvre rapidement. Les mesures d’intégration concernaient l’implication les acteurs chargés de la formation : informations sur le dispositif retenu, sensibilisation sur l’ E.A.O, concertation pédagogique. Quant au dispositif, il s’architecturait de la façon suivante :
Nous distinguions deux parcours de formation afin de répondre au mieux aux besoins des Centraux :
Cette distinction entre nouveaux Centraux et Centraux expérimentés était principalement due à la formation administrative à laquelle devaient participer les nouveaux, et à leur inexpérience de l’utilisation de ZeLogiciel. Compte tenu de ces deux points, nous proposions des parcours adaptés. Ils présentaient des similitudes et utilisaient des moyens, méthodes et supports communs dont le support E.A.O.
Nous définissions un E.A.O central aux deux parcours de formation sous la forme d’un tutoriel qui prenne en charge la plus grande partie des contenus liés aux domaines d’application et à l’outil informatique. Celui-ci devait permettre une capitalisation des savoirs et une meilleur formalisation de ceux-ci. Il devait aussi constituer un premier pas vers l’établissement d’une référence commune à tous les Centraux grâce à l’uniformisation du message pédagogique.
Le choix d’un E.A.O central était la solution qui optimisait le mieux l’utilisation des ressources du ClientEntreprise et qui en plus, prolongeait naturellement les pratiques d’autoformation des Centraux en vigueur au sein du réseau. Il répondait aussi pour le ClientEntreprise, aux principales attentes stratégiques qui caractérisent son introduction en formation : une logistique légère du dispositif ; une individualisation forte dans la réponse aux besoins des apprenants ; le maintien des apprenant à proximité de leur lieu de travail ; une liberté de choix du moment consacré à l’apprentissage grâce à l’autoformation.
Pour compléter l’ E.A.O, une formation présentielle intervenait dans le parcours de façon auxiliaire en amont de l’ E.A.O. D’une durée minimum d’un jour, elle portait sur les thèmes suivants :
Il nous semblait doublement intéressant dans le contexte du ClientEntreprise de conserver un rôle à la formation présentielle et de traiter par son biais des sujets qu’il serait peu opportun d’inscrire au programme de l’ E.A.O. Il fallait conserver dans le dispositif la " philosophie de l’exemple ", le partage des expériences et la dimension sociale de la formation. Celle-ci le permettait.
Le dispositif prévoyait la restructuration des sites de formation et la transformation temporaire de deux d’entre-eux en centres techniques de formation. Ces lieux devaient permettre l’accueil des Centraux au rythme moyen de 10 à 12 par jour pendant 6 mois. Chaque centre disposerait de deux équipes :
Cette organisation présentait l’avantage de mobiliser les Centraux sur une seule journée ; ces derniers arrivant le matin avec leur ancien ordinateur, participant à la formation pendant la journée, et repartant le soir avec leur nouvel ordinateur et les connaissances de base pour s’en servir et entamer leur autoformation.
La migration des données était une opération trop délicate pour qu’elle fusse laissée à la charge des Centraux. Le ClientEntreprise avait donc budgèté celle-ci sur le projet ZeLogiciel et non pas sur le projet de formation. Nous trouvâmes opportun de faire converger la formation présentielle avec cette étape indispensable ; l’échange de matériel et la migration devaient s’effectuer sur quelques heures et impliquait un déplacement de la part des Centraux, d’où une meilleur utilisation du temps et un gain important sur l’ensemble du projet. Cette convergence occasionnait aussi une réduction des dépenses, puisqu’un seul et même site servait à la fois de centre technique et de centre de formation. Enfin, les Centraux ne se déplaçaient qu’une fois au lieu de deux, ce qui réduisait d’autant leurs frais divers et leur absence du terrain. Cette proposition retint toute l’attention de notre commanditaire, et fut décisive dans son acceptation du dispositif que nous lui préconisions.
Le dispositif comprenait un suivi technique et pédagogique utilisant et adaptant les ressources que représentaient la permanence d’assistance téléphonique. Il s’agissait de mettre en place une équipe ressource, constituée des trois techniciennes et de deux formateurs, qui appliquerait un plan de suivi et organiserait une remontée d’informations directement exploitables par la suite. Ces données collectées devant servir aux adaptations éventuelles du dispositif de formation, à son évaluation, et aux futures mises à jour des supports ; tutoriel et autres supports d’autoformation, documentation, aide en ligne.
Nous pensions que le suivi technique et pédagogique s’avérerait réellement utile et relativement simple à mettre en place, et ce compte tenu de l’existence d’un service déjà en place, du risque de problèmes supplémentaires lié aux nouvelles stations, et du comportement type des Centraux.
Le dispositif prévoyait enfin un pilotage du projet de formation à deux niveaux sur l’ensemble de la période effective de mise en oeuvre. La dimension stratégique du projet était à la charge d’un groupe de pilotage composé de notre commanditaire, d’un membre supplémentaire du Comité de Direction, et de deux consultants d’Fournisseur1 assurant le rôle de conseil. La dimension opérationnelle du projet était du ressort des équipes, qui se rassemblaient en un groupe action composé des acteurs permanents du ClientEntreprise, du fournisseur du NouveauSystème et du Fournisseur1 travaillant sur et autour de ZeLogiciel 5. Le groupe action pouvait faire appel ponctuellement à diverses personnes - telles que des contributeurs -susceptibles de fournir des informations ou de participer à des décisions.
Le pré-concept E.A.O devait satisfaire à une liste d’exigences pédagogiques que nous avions identifiées au cours des phases 1 à 3 de l’étude. Ces exigences allaient dans le sens d’un meilleur accompagnement des apprenants durant leur autoformation et d’une prise en compte avancée de l’hétérogénéité du public sur la plupart des critères typologiques. En revanche, le pré-concept pouvait largement s’appuyer sur une configuration matérielle d’assez bon niveau avec des capacités multimédia à la norme MPC 2.
Compte tenu de la distinction " manipulations / domaines d’application ", je conçu un tutoriel en deux parties distinctes. Chaque partie proposait à l’apprenant une approche différente suivant qu’il chercha à accomplir une tâche précise sur son ordinateur dans le quart d’heure suivant, ou qu’il consacra une heure à élargir ses connaissances en droit commercial par exemple. La scénarisation pédagogique différait donc selon les objectifs de l’apprenant. Il en était évidemment de même des méthodes pédagogiques. La partie " domaines d’application " devait favoriser la réflexion et la compréhension, alors que la partie " manipulations " devait privilégier l’action et la réalisation.
Il me fut aisé d’établir un pré-concept cohérent avec le dispositif de formation retenu, et adapté aux besoins des apprenants ; je disposais pour cela de nombreuses données qui, bien qu’incomplètes, représentaient somme toute une excellente base, propice à un travail de préconception. Pour m’assurer de ne pas omettre un point important, j’utilisais la méthode de questionnement que propose le logiciel MEDA. Celui-ci me permit d’une part, de réfléchir à des aspects que jusqu’alors, je n’avais pas encore abordés dans le détail ; et d’autre part, de conforter certaines de mes idées de départ. Je trouve que l’intérêt de MEDA réside dans le questionnement exhaustif qu’il propose sur des aspects divers, tels que la culture d’entreprise, l’approche pédagogique ou l’ergonomie du tutoriel. La réflexion qu’entraîna ce questionnement fut pour moi génératrice d’idées. Comme je détenais déjà les réponses à la plupart des questions, ces idées s’assemblèrent facilement pour former le pré-concept. Je fut d’ailleurs surpris par la facilité avec laquelle j’accomplis ce travail ; si bien que j’en vins à douter de la validité de mes résultats. Je procédai alors à une vérification de la cohérence de l’ensemble au terme de laquelle je fut vite rassuré. En définitif, cette étape n°15 se déroula fort bien.
Il en fut tout autrement de l’étape n°16, étape de validation du pré-concept avec le service informatique du ClientEntreprise. Je précise tout de suite, que le pré-concept validé fut à peu de choses près celui que je proposai initialement ; mais la validation intervint après de nombreuses tergiversations portant sur les deux points suivants :
Implémentation du tutoriel : le C.P.I souhaitait que le tutoriel fusse On-line, accessible par une connexion sur le réseau. Compte tenu des performances attendues du tutoriel, cette implémentation ne pouvait se faire sans causer de gros inconvénients, notamment au niveau de l’interface Homme-machine et de la dimension multimédia des échanges. De plus, cette solution aurait complexifié le développement du tutoriel en instaurant une relation de travail supplémentaire entre Fournisseur1 et Fournisseur2. L’implémentation Off-line s’imposa comme la solution la plus raisonnable, la moins coûteuse, et le support C.D. ROM fut finalement retenu.
Relations tutoriel / logiciel : il me fallut faire entendre au C.P.I que l’ E.A.O avait un rôle différent de l’aide en ligne. Le C.P.I assimilait les deux et pensait que l’accès au tutoriel devait s’effectuer par une simple pression sur une touche de fonction ; ce qui selon moi ne convenait ni à la démarche d’autoformation, ni aux situations de travail. Je craignais que ce mode d’accès conduise les apprenants à faire l’amalgame du logiciel et du tutoriel ; une éventuelle confusion - à l’instant d’une demande d’aide de leur part - aurait pu s’avérer préjudiciable. Et pour cause, j’envisageais déjà que cette partie du tutoriel reproduise fidèlement l’environnement de travail, et l’idée qu’un certain nombre d’apprenants puisse rejeter l’ E.A.O en raison du fait qu’ils en cerneraient mal l’utilité (ou qu’il le trouveraient compliqué) ne me plaisait guère. Je demandai donc à ce que les modes d’accès à l’aide du logiciel et au tutoriel fussent distincts. Il fut alors décidé d’une solution intermédiaire : à partir de n’importe quel écran de ZeLogiciel 5, la touche F1 permettrait d’accéder à une page d’aide en ligne réduite ; en complément des informations de l’aide en ligne, une liste de tâches en hyper-texte permettrait à l’utilisateur de passer directement à la partie correspondante du tutoriel. L’accès au tutoriel serait aussi possible sans passer par ZeLogiciel 5. Cette solution nous parut très bonne, car elle établissait une distinction entre les situations de travail et les situations d’apprentissage ; le choix de l’une ou de l’autre restant à l’initiative de l’utilisateur.