Navigation – Plan du site

AccueilNuméros7-1Modélisation, faire et dire du fa...

Modélisation, faire et dire du faire pour des informaticiens engagés dans une démarche de VAE

Modelling, performance and analysis for computer specialists applying for work experience accreditation
Bruno Cuvillier, Gérard Canesi et Pierre Pastré

Résumés

La VAE introduit une rupture entre la formation et la certification. La possibilité de se voir délivrer une certification sans passer par la formation pose le délicat problème de l’évaluation de l’expérience. En s’inscrivant dans le courant de la conceptualisation dans l’action, notre étude s’attache à mieux comprendre l’expérience de candidats informaticiens engagés dans une VAE, en les soumettant à une tâche de modélisation explicitée. Notre analyse a consisté préalablement à mettre à jour la structure conceptuelle de la situation, ensemble des dimensions de la tâche à prendre en compte pour que l’action soit efficace. Cette structure conceptuelle s’articule autour de trois dimensions que sont : (1) la maîtrise d’un langage, (2) L’utilisation de ce langage pour s’engager dans un processus de conception plus ou moins étendu, (3) L’adressage prioritaire de cette conception à un autre professionnel, un utilisateur ou au chercheur En s’appuyant sur cette structure conceptuelle, nous avons dégagé six profils d’informaticiens mobilisant des modèles opératifs différents.

Haut de page

Notes de la rédaction

Article soumis le 6 février 2009, accepté pour publication le 1er février 2010.

Texte intégral

« Nous ne raisonnons que sur des modèles »
Paul Valéry

1. Introduction 

  • 1 Validation des Acquis de l’Expérience : Loi de modernisation sociale du 15 janvier 2002.

1Parmi les nombreux dispositifs proposant à l’expérience professionnelle de se penser hors des situations de travail, la VAE1 invite les candidats à décrire leur activité en faisant ressortir ce qu’elle leur a permis d’apprendre en lien avec les référentiels d’un diplôme visé. On se situe dans une prescription de communication d’expérience (Astier, 2001, p. 23) qui présente la particularité dans l’enseignement supérieur de s’appuyer exclusivement sur le langage.

2Un des problèmes posés par les dossiers de validation des acquis de l’expérience est qu’ils s’inscrivent dans un paradoxe dont il semble impossible de les faire sortir : d’une part, il s’agit pour le candidat de faire la preuve qu’il possède les compétences requises par l’activité dans laquelle il travaille. Or une compétence, quelle qu’elle soit, ne se manifeste que dans l’activité qui amène le sujet à la mobiliser. Il revient donc au candidat de faire la preuve de son « savoir faire » en démontrant la pertinence de son « faire ». Mais, d’autre part, comment donner à voir ce qu’on sait faire dans le quotidien de son travail autrement qu’en racontant ce qu’on a fait ? C’est la raison pour laquelle la quasi-totalité des dossiers de VAE reposent sur un discours qui cherche à donner à voir un agir. Faute de pouvoir montrer directement son activité, on l’évoque par un récit, au mieux par une analyse qui l’accompagne. Il est probable que le dispositif VAE produit moins des compétences d’action que des « compétences de gestion et de rhétorique de l’action » (Barbier & Galatanu, 2004, p. 76)

3Les hypothèses sur lesquelles repose la didactique professionnelle partent d’un point de départ tout différent : il n’est pas sûr que le discours sur l’activité éclaire beaucoup l’activité. Ainsi, un discours brillant peut accompagner une activité médiocre. Mais surtout, y compris dans les activités de très haut niveau, il arrive souvent que des acteurs très compétents sachent faire des choses sans être capables d’expliquer comment ils les font : le laconisme des experts est un des thèmes qui a été beaucoup développé en ergonomie. C’est la raison pour laquelle la didactique professionnelle repose sur quelques hypothèses de base : 1/ L’activité humaine (on pense notamment à l’activité professionnelle) comporte une organisation interne, qui la rend efficace, reproductible et analysable. 2/ Cette organisation interne est constituée d’un certain nombre de concepts organisateurs, qui ne sont pas forcément explicites pour le sujet, mais qui sont mobilisés dans l’action. 3/ Une analyse de l’activité permet d’identifier cette « structure conceptuelle de la situation » (Pastré, 1997) et permet ainsi de faire une analyse intrinsèque de l’action, sans être prisonnier du discours tenu par les acteurs. L’analyse de l’activité (et non du discours sur l’activité) est ainsi le fil conducteur qui guide la didactique professionnelle.

  • 2 CNAM : Conservatoire National des Arts et Métiers

4Comment transposer ce cadre théorique à la question de la validation des acquis de l’expérience ? Comment, en VAE, mettre l’analyse de l’activité au cœur de la démarche ? On a voulu enrichir la démarche de constitution d’un dossier de VAE y associant une analyse de l’activité du candidat, invité à produire une modélisation d’une situation/problème. Cela ne veut pas dire qu’on récuse la démarche usuelle, dont on verra qu’elle est probablement incontournable. Mais cela veut dire qu’on a cherché à éclairer cette démarche en confrontant ce que disent les professionnels aux traces de leur activité. On a choisi une population d’auditeurs du CNAM2, dans le domaine de l’informatique, qui ont déposé un dossier de VAE. À ces sujets on a donné une tâche à effectuer, tâche dont on pensait qu’elle devait mobiliser les compétences essentielles correspondant à ce métier. L’analyse de cette activité a permis, à travers l’identification de stratégies diverses selon les acteurs, d’accéder à l’organisation de l’activité au-delà des discours tenus sur elle. Attention ! Nous ne sommes pas allergiques aux discours sur l’activité. Le lecteur se rendra compte que nous avons intégré l’analyse des discours des acteurs sur leur activité dans notre analyse. Mais nous avons pu le faire parce qu’à l’origine nous disposions des traces d’un « faire », qui a constitué le noyau central de notre analyse. Pour une meilleure compréhension de notre propos, nous présenterons dans un premier temps la démarche classique d’un candidat engagé dans une VAE. Nous préciserons ensuite ce que recouvre la modélisation en informatique, activité fréquemment évoquée par les professionnels. Nous proposerons une catégorisation en termes de profils auxquels se rattachent des stratégies. Enfin, nous présenterons quelques réflexions visant à ouvrir le dispositif actuel de VAE à une forme d’analyse de l’activité.

2. La VAE : Une démarche exigeante

5De nombreux travaux produits dans le champ de la VAE (Aubret, 2003 ; Clot & Prot, 2003 ; Feutrie, 2003 ; Mayen, 2006) mettent en évidence l’important travail réflexif produit par le candidat lors de la réalisation de son dossier. Pour Astier (2008), l’examen de soi au travail par un contrôle écrit de ce que l’on fait, est « un redoutable activateur de réflexion sur soi ».

6D’autres travaux soulignent l’aspect formatif de cette démarche (Cuvillier, 2004 ; Liétard & Merle, 2004 ; Rivoire, 2006). Pour permettre au lecteur de mieux appréhender la spécificité de cette démarche, nous proposons de décrire les trois grandes étapes de ce processus :

a) L’information et le choix de la certification

  • 3 PRC : Point Relais Conseil, CIO : Centre d’Information et d’Orientation

7Dans un premier temps, le candidat doit identifier parmi les certifications existantes, celle qui lui semble la plus proche de son expérience. Il peut s’adresser à un réseau institutionnel (PRC, CIO3,..) qui l’aidera à prendre connaissance de l’étendue des certifications existant dans son champ professionnel. Cette première démarche lui permet souvent de découvrir un référentiel, décliné plus ou moins précisément sous forme de compétences.

b) L’élaboration du dossier

8Cette phase de la démarche consiste à produire un dossier écrit, qui retracera à la fois le parcours professionnel et extra-professionnel, ainsi que les situations décrites susceptibles d’illustrer la maîtrise des compétences, connaissances et aptitudes en lien avec la certification visée.

9L’accompagnement n’étant pas obligatoire par la loi, le candidat peut se retrouver seul face à cet exercice exigeant d’écriture. Si le dossier remis est informatif (commentaires, conseils, cadrage de la tâche), le remplir sans bénéficier d’un accompagnement nous semble être une tâche ardue. Pour autant, le regard réflexif à mobiliser pour mettre à jour les compétences « enfouies » et en dégager la pertinence en lien avec le référentiel est facilité par des entretiens d’explicitation. Ces entretiens visent à guider le questionnement du candidat, en se centrant sur certaines situations perçues comme reflétant au mieux les compétences attendues par le détenteur de la certification. Par ailleurs, le travail consiste à se centrer sur le « comment » de l’action, qui est souvent éclipsée dans le discours des candidats par le « pourquoi ». L’analyse réflexive vise à produire un récit, qui s’ancre dans l’activité réelle du candidat. Spontanément, la majorité des candidats développent leur activité à partir de leur fiche de poste, ce qui est attendu par l’organisation, plus rarement ce qu’ils font effectivement et comment ils s’y prennent.

10Dans le cadre de cette fonction d’accompagnateur, le conseiller s’attache à transmettre la grille de lecture et d’évaluation du jury. Or, les critères d’évaluation sont parfois peu explicites, variables selon les membres et peu débattus au sein des jurys. Une étude (Cuvillier & Faudière, 2009) montre un décalage important entre les attentes des candidats en termes d’évaluation et les questions posées par les membres du jury lors de l’entretien. Ainsi, les candidats expriment leur incompréhension du processus évaluatif en jeu. Certains disent percevoir une centration quasi exclusive sur des indicateurs statutaires (coefficient conventions collectives, positionnement dans l’organisation, intitulé de poste), une vision académique (recherche de connaissances, vision pointilliste des compétences), une difficile prise en compte du développement dans et à partir des situations professionnelles ou extra-professionnelles. Enfin, la richesse et l’analyse des situations développées dans le dossier ne sont pas suffisamment prises en compte lors de cette rencontre. Alors que ces candidats s’attendaient à débattre à partir des situations, ils perçoivent une résistance des membres à entrer dans l’activité. Cette étude interroge les aménagements possibles, pour tenter d’intégrer une démarche d’analyse de l’activité complémentaire au discours tenu sur l’activité.

c) L’évaluation du jury

11Dans l’enseignement supérieur, le jury mixte est constitué d’une majorité d’enseignants chercheurs et d’un ou deux professionnels. Le candidat, reçu en entretien, présente généralement son évolution professionnelle, et répond aux questions posées par le jury, sur le dossier réalisé. Le jury peut accorder tout ou partie de la certification sollicitée. Le candidat doit alors, valider académiquement les modules de formation non accordés ou redéposer ultérieurement un dossier, si son expérience a été enrichie.

3. Pourquoi avoir recours à la modélisation ?

12L’option consistant à revenir sur le faire et à en saisir l’intelligibilité à travers ses traces (diagrammes, modèles, schémas) commentées, nous permet de questionner, voire de clarifier ce que nous donnent à entendre les candidats de leur expérience professionnelle. Les modèles produits sont des observables susceptibles de nous livrer, à travers le « faire » et le « dire du faire » des candidats, l’expression du concept en mouvement « non pas dans sa forme statique, isolée, mais dans les processus vivants de la pensée, de la résolution d’un problème » (Vygotsky, 1934-1997, p. 202). Il ne s’agit pas de revenir aux sources d’une activité supposée « corrompue » par une reconfiguration et une mise en mots, mais de tenter d’en saisir une organisation via un modèle explicité. Il nous semble que le dispositif VAE n’offre pas la possibilité d’exprimer tous les savoirs et compétences, mais principalement ceux que la situation de communication rend manifeste. Se pose également la question de bien saisir pour le professionnel ce qui est reconnu par le jury comme relevant d’une expérience digne d’être dite. Par ailleurs, il nous semble que certaines organisations de l’action transparaissent insuffisamment dans les dossiers des candidats, à l’étroit dans le cadre du référentiel de la certification visée. Enfin, cette approche d’une modélisation commentée vise ainsi à confronter un discours au travail ou ce qui s’en rapproche (production d’un modèle à partir d’un énoncé flou, ambigu) d’un discours à propos du travail (écrit dans le dossier VAE).

3.1. Qu’est-ce qu’un modèle ?

13Nicolas Bouleau (1999) évoque « une représentation destinée à éclairer et à préparer la décision d’un acteur spécifié ou de plusieurs acteurs en situation de dialogue ». Il précise par ailleurs que cette action consistant à produire des modèles (modélisation) « ne descend plus d’un savoir théorique vers une réalité soumise, elle remonte et fait émerger une configuration plus riche, plus complexe et plus vivifiante qu’une simple instanciation de règles générales. Il [le modélisateur] est pris dans un engagement. […]. Les modèles qu’il élabore sont donc des représentations partisanes, je dirais au bon sens du terme, c’est-à-dire le choix d’un parti au sein de possibilités d’expression multiples ». La vision développée par Bouleau rejoint pleinement les résultats présentés dans cet article. Interface entre le faire et le comprendre, le modèle apparaît être un support de réflexion pour l’informaticien, de dialogue et de négociation avec le client. Projection des intentions du modélisateur, le modèle construit déborde souvent la simple représentation d’un énoncé ou cahier des charges transmis par le client. Outre le passage d’un univers informationnel informel à une représentation formelle grâce à un système de signes, le modèle traduit plus ou moins complètement une vue commune aux utilisateurs et concepteurs.

3.2. Des travaux dans le champ de la psychologie de la programmation

14Les travaux en psychologie cognitive en lien avec l’activité de programmation au sens large (analyse, conception, codage et maintenance) ont fait l’objet par Détienne (1998) d’une recension et d’une synthèse critique. Cet auteur montre comment la psychologie de la programmation est passée d’une période a-théorique à une période inspirée par la psychologie cognitive et d’une façon plus marginale, à l’intelligence artificielle. Il précise également que l’on assiste à une évolution méthodologique délaissant partiellement les études expérimentales isolées, au profit d’études de type clinique axées sur des analyses fines de l’activité débouchant sur la construction de modèles descriptifs. Par ailleurs, les travaux menés majoritairement auprès d’étudiants ou de novices posaient le problème de la généralisation des connaissances acquises dans ce domaine. Les nouvelles thématiques récentes abordent également l’activité d’experts, l’aspect collectif/collaboratif dans le développement du logiciel, les activités en amont du codage, e.g, la spécification ou la conception (Idem). D’autres travaux plus récents se sont centrés sur la modélisation comme « tâche au cœur du métier » (« core task » au sens de Norros et Nuutinen, 2002).

3.3- La modélisation en informatique

15La modélisation en informatique consiste à produire un modèle qui décrive complètement le contenu fonctionnel d’un programme.

16La réalisation de ce modèle doit « progresser par étapes caractérisées chacune par la confection d’un diagramme, la démarche procédant par enrichissement progressif selon un ordre top down » (Volle, 2005). Ces étapes se réalisent dans un ordre en s’appuyant préalablement sur l’expression des besoins. La démarche nécessite d’associer « plusieurs techniques informelles et formelles pour saisir les diverses facettes d’un problème sans le dénaturer, puis pour le détailler dans un modèle central que l’on pourra préciser et modifier jusqu’à l’implémentation » (Idem).

17Le modèle constitue alors un langage, disposant de propriétés graphiques et iconographies plus propres à exprimer une activité de conception. De même qu’il autorise la communication entre acteurs différents, le modèle permet sur un plan cognitif de servir de support à la réflexion du concepteur, c’est-à-dire de communiquer avec la représentation en cours d’élaboration. Selon Pierre Lévy (1991), le langage idéographique semble plus adéquat à ce type de tâche cognitive que le traditionnel texte écrit. Si on admet qu’ « un bon dessin vaut mieux qu’un long discours », on perçoit mieux pourquoi les analystes utilisent abondamment des rectangles, ronds et autres flèches pour représenter le réel. Ce recours à un modèle élaboré à partir d’un langage, capable de manipuler un jeu volontairement réduit de signes, à interprétation univoque, aisément communicable et support à la réflexion par modification de l’agencement de ces signes (modification graphique, immédiatement visualisable), est un outil privilégié de la conception. Toutefois, ce formalisme rigoureux laisse souvent place à des modes d’expression alternatifs, plus compréhensibles parmi les acteurs économiques (e.g. décideurs, clients, utilisateurs, techniciens,…).

3.4. Une modélisation, interface entre la structure conceptuelle et l’image opérative

18Toute activité de conception en informatique repose préalablement sur l’analyse des besoins. En fonction de cette analyse des besoins, le modèle produit mettra l’accent sur certains aspects du réel jugés pertinents pour la représentation du problème.

19Cette construction résultant d’une perception sélective du réel, qualifiée par Ochanine d’image opérative (sélective, fonctionnelle, déformée), est orientée vers le ou les buts de l’action.

20À ce propos, Pastré (1999) définit la structure conceptuelle d’une situation professionnelle, comme « le noyau conceptuel qu’il faut prendre en compte pour que l’action soit pertinente et efficace. Il s’agit de la ou des dimensions essentielles de la situation, autrement dit du ou des concepts qu’il faut pouvoir évaluer pour faire un diagnostic de la situation, repérer son état présent et son évolution probable ». Il suggère d’articuler les traits caractéristiques d’une situation et la représentation que le sujet s’en est construite. Si la dimension propre à la situation apparaît importante, elle n’éclipse pas pour autant le professionnel, en évoquant l’activité, définie par son intentionnalité. Elle correspond ainsi à la manière dont un acteur adapte la situation à lui-même. On pourrait dire que, pour une action identique (modélisation d’une application), impliquant une même structure conceptuelle de la situation, les différents professionnels déploient une activité différente, traduisant une organisation de l’action à chercher non seulement du côté de la structure de la situation, mais aussi et surtout du côté de l’expérience de chacun des professionnels. On relèvera à travers les différents modèles produits et commentés les stratégies de ces candidats, que nous analyserons.

3.5. Sous le modèle… la structure conceptuelle

21À la différence des activités de conduite, de maintenance ou de gestion, les activités de conception sont des activités « ouvertes » : elles ne peuvent pas se déterminer par rapport aux caractéristiques de la situation qui est en face de l’acteur, puisque cette situation sera, en partie au moins, produite par l’activité de l’acteur. Même si c’est pour une part relativement mince, il y a de l’invention dans une activité de conception. Conséquence : le résultat de l’action ne réside pas en une seule bonne solution. Il y a des solutions, plus ou moins adaptées, plus ou moins habiles et astucieuses. Il n’y a donc pas un modèle de l’action réussie qui pourrait servir de référent à l’analyse de l’activité des concepteurs.

22Dans le domaine informatique, la dimension de conception de l’activité implique :

  • l’utilisation d’un langage,

  • la construction d’un objet répondant à un problème,

  • le fait que cet objet est adressé à d’autres acteurs : utilisateurs, partenaires ou exécutants.

23À ces trois dimensions de l’activité, il faudrait ajouter une quatrième composante très liée à la troisième : la position occupée par l’acteur principal : chef de projet, développeur, etc.

24Le professionnel confronté à une tâche de modélisation mobilise un mode de pensée, se référant plus ou moins directement à un paradigme de programmation, qui oriente la façon d’analyser, de concevoir et de coder une application. Ainsi, le recours et le niveau de maîtrise d’un langage plus ou moins évolué offrent une puissance d’expression, voire une façon différente de poser le problème. Toutefois, un système formel qu’est un langage informatique, ne présente pas un caractère « autosuffisant », car n’indiquant pas « dans un contexte donné, ni comment définir la « bonne » structure, ni comment sélectionner les « bonnes » opérations parmi celles qui sont autorisées » (Morand, 1995). Par ailleurs, il s’engage dans une activité de conception, qui déborde fréquemment la seule tâche de modélisation prescrite en faisant œuvre d’anticipation comme le mentionne Béguin (2004) : « L’anticipation de l’homme et de son activité est partie intégrante du processus de conception. Tout dispositif technique, tout artefact, mobilise durant sa conception une connaissance, une représentation, et au sens le plus large un modèle de l’utilisateur et de son activité ». Enfin, ce processus de détermination d’un objet ou d’une situation de travail et des actions des acteurs de la conception présente la caractéristique d’être progressif (Terssac, de & Frieberg, 1996). La solution finale n’émerge pas spontanément et résulte d’un compromis plus ou moins marqué en fonction des contraintes et ressources prises en compte. Il n’existe alors pas une bonne ou mauvaise solution mais des solutions plus ou moins acceptables.

25Comme nous le préciserons, le professionnel se projette dans les étapes ultérieures en développant un modèle adressé prioritairement au client ou au développeur, chargé de coder l’application. Ce triptyque (paradigme de programmation, activité de conception et activité adressée) constitue une structure de variables en interaction à partir de laquelle le professionnel va déployer son activité, orientée par un ou des but(s) hiérarchisé(s). Nous pourrions y ajouter un organisateur fort qu’est le couple coût/efficacité, qui renvoie à la pression ressentie, au sein d’une entreprise, pour mener à bien un projet. Évoqué fréquemment lors des entretiens, il conditionne ou justifie aux yeux des professionnels le choix ou non de s’attarder sur la phase préalable de l’analyse des besoins et de produire le cas échéant un modèle. Il oriente par ailleurs significativement certaines stratégies, en faisant ressortir des attitudes différenciées dans la prise en charge du problème.

3.6. Une activité adressée

26La structure conceptuelle, telle que nous l’avons dégagée, laisse émerger une variable pivot, que nous dénommerons activité adressée. Elle traduit qu’une activité de conception s’intègre dans un collectif et repose sur une communication, vecteur privilégié d’une co-conception.

27Lors de l’élaboration du modèle, on relève des tentatives de faire émerger la signification, en enrichissant l’imprécis et le vague à travers les questionnements inter (en direction du client) et intra (en direction de son propre modèle). Ces questionnements s’inscrivent dans un échange asymétrique entre un client « supposé savoir » et un professionnel en quête « de savoir ». C’est en partie cette incompréhension réciproque qui s’avère être un moteur de développement professionnel, dans la mesure où l’informaticien se met à l’écoute des besoins du client, sans les présupposer.

28La position consistant à adopter un regard neuf, ou du moins, se garder de se faire une idée prématurément, semble caractéristique de certains professionnels expérimentés : « Il faut s’entendre sur ce que l’on parle, c’est contractuel. C’est important au départ de rester sur des choses hors implémentation, il n’y a plus cet aspect, l’informaticien possède ce background technique qui lui fait dire qu’il ira plutôt dans cette direction en fonction des contraintes repérées, ce que n’aura pas son interlocuteur non-informaticien, ce qui fait que l’on est dans la position idéale pour ne pas se comprendre (…) moi, j’essaye d’y faire attention, quand je parle à un non-informaticien, j’essaye de ne pas trop impliquer mon background, c’est très dur, quand on parle d’un projet, le fait d’avoir ce background, ça occupe tout une partie de la problématique ».

29Ainsi, l’analyste oscille entre la vision du client et la sienne même s’il s’en méfie ou s’en protège. Il s’agit parfois de refouler un point de vue pressenti comme prématuré ou biaisé pour davantage se laisser le temps de se construire une représentation du problème. Ce jeu de renvois successifs l’amène à s’approprier progressivement le questionnement du client (besoins du client) pour initier son propre questionnement susceptible de relancer à nouveau le questionnement auprès du client ; mouvement initié de l’inter à l’intra, puis de nouveau vers l’inter. En se référant à la genèse instrumentale, on retrouve ce double mouvement impulsé chez certains analystes qui se traduit par leur capacité à susciter un questionnement centré sur le client ou/et sur soi-même, à travers l’objet de sa conception. De cette capacité à questionner autrui, pour mieux questionner le modèle ébauché, résulte non pas seulement une appropriation par lui mais pour lui. À travers cette appropriation pour lui, il s’appuie sur cet instrument au sens de Rabardel (1999) pour « façonner » son image opératoire. Il revient dans notre étude à l’analyste de s’approprier grâce à un questionnement « pertinent » la représentation du réel de son client, pour développer sa propre représentation qu’il soumettra en retour à ce même client. « C’est essentiellement ça, si vous ne dialoguez pas, vous ne pouvez pas faire un logiciel qui est pour un utilisateur, si vous vous faites plaisir avec un super soft en C, avec plein de menus, mais le mec au bout, il en sait pas par quel menu il doit passer pour faire sa fonction de tous les jours, c’est idiot, c’est un logiciel qui ne sera jamais utilisé »

30Ce processus itératif, visant à changer successivement les regards portés sur le modèle, stimule le processus de conception qui peut s’illustrer par l’expression « faire vivre la spécification » utilisée par ce candidat : « C’est la vie du système, c’est une conception, à la base on n’aura pas pensé à tout, on essaye de penser à un maximum de choses et au fur et à mesure, on fait vivre, on va régler un problème à côté et en réfléchissant, on va dire on peut pas le faire comme cela, on essaye de le faire à haut niveau, tant qu’on est au niveau de la spécification, ça évolue, quand on est dans le codage, on a dit ok, on a figé les idées car le client final est d’accord. Le plus important, c’est réaliser le travail de spécification… ».

3.7. Une activité adressée à d’autres professionnels

31Le modèle conçu nous apparaît être un support de dialogue avec le client, il vise également pour certains candidats à renseigner un autre professionnel chargé de développer l’application, sur certaines options du concepteur. Ce dialogue via un modèle interposé, ces clins d’œil, suggestions pour faciliter le codage, signent en général l’appartenance à des fonctions proches. Elles sont le fait de développeur, de chef de projet technique mettant volontiers selon leurs dires « les mains dans le cambouis ». Ainsi, prendre en compte les contraintes ou les ressources des équipes sollicitées dans les phases ultérieures de production s’avère-t-il être un marqueur de professionnalité. Les extraits d’entretiens proposés ci-dessous proviennent de deux chefs de projets, justifiant d’une longue expérience (15-20 ans) sur des postes variés. Ils affirment la nécessité d’intégrer les contraintes ou les ressources dans ses propres préoccupations, pour agir efficacement et s’engager dans une co-conception.

« …Ce que je reproche aux gens, c’est de dire tu fais comme cela, sans connaître les contraintes de son collègue d’à côté, parce que moi, je fais de la conception, je me fais plaisir mais l’autre qui va fabriquer a ses problèmes de process, d’évolution d’outil, quand vous dîtes j’ai fait une modification de trame, un truc tout bête, l’autre avec son outil fabriqué par un prestataire externe, il va mettre 3 mois pour adapter, ce sont souvent des choses qui ne sont pas prises en compte ».

32Pour cet autre candidat, il faut non seulement prendre en compte les contraintes, mais tirer partie de la maîtrise d’un outil spécifique. On repère à quel point la phase d’analyse est dépendante du but assigné ou que s’assignent ces professionnels, qui sont insérés dans un environnement de production marqué par une optimisation des coûts.

« Je pense que dans une analyse, il y a deux théories qui se confrontent : il y a des gens qui disent que l’on doit faire une analyse indépendante de l’outil à utiliser, l’analyse doit être universelle, on doit pouvoir transposer l’analyse, la donner à n’importe quel développeur et quel que soit l’outil qu’il utilise, il se débrouille, c’est une théorie revendiquée par beaucoup de gens, moi, je m’inscris en faux, je ne suis pas d’accord, il faut profiter de l’expérience acquise sur un outil de développement pour analyser en fonction de cet outil, on ne part pas vierge, on part avec ses acquis, ça permet de ne pas aller dans les décors, il y a des équipes qui ne savent pas faire telle ou telle chose, ce n’est pas la peine, il faut s’organiser pour que l’analyse oriente les modes de raisonnement pour que l’on sache les traduire facilement avec l’outil ».

4. Méthodologie

33Notre étude porte sur 35 professionnels de l’informatique justifiant d’une expérience comprise entre 5 ans et plus de 20 ans. Ces personnes avaient préalablement engagé une démarche de validation des acquis de l’expérience, afin de se voir délivrer un diplôme de l’enseignement supérieur de type bac + 2 (n = 4), bac + 4 (n = 15), diplôme d’ingénieur (n = 16). Nous avons retenu pour notre étude les candidats engagés prioritairement dans une demande de validation totale ou quasi totale (3/4 du diplôme). Les caractéristiques plus précises (type de validation souhaitée, diplôme initial, nombre d’années d’expérience, taux de validation obtenu) de cette population figurent en annexe 1.

34Nous leur avons soumis un problème (cf. annexe 2) en les incitant à concevoir un modèle susceptible de déboucher plus tard sur une application qui réponde à la demande d’un client. La consigne insistait sur la nécessité d’inscrire cette activité dans une perspective professionnelle. Il nous importait de recueillir des traces au plus près de leur activité professionnelle actuelle, en leur demandant néanmoins de décliner d’autres modèles, le cas échéant, produits dans le cadre d’autres fonctions occupées antérieurement.

35Nous leur avons suggéré avant la réalisation de cette tâche d’être attentif à leur raisonnement, de noter leur cheminement intellectuel.

  • Lors d’un entretien ultérieur, le candidat développait sa démarche mentale, ses interrogations, ainsi que le modèle produit. Nous avons procédé à un questionnement ouvert, centré sur la compréhension des stratégies mises en œuvre lors de la construction du modèle et sa fonction au sein d’une activité réelle.

  • Nous avons également questionné ces candidats (confrontation « croisée ») à travers la présentation de modèles produits par d’autres candidats. Cette confrontation s’est avérée un levier efficace pour relancer les justifications, susciter des réactions voire engager le candidat dans une situation potentielle de développement (Mayen, 1999).

5. Résultats

5.1. Une stratégie clivée autour de « quelle est la solution » ou « de quoi s’agit-il ? »

36Engagés dans ce problème de modélisation, les candidats déploient deux stratégies génériques articulées autour soit du choix d’une solution technique soit du choix d’une solution par identification du problème.

37Une première stratégie (choix d’une solution technique) repérable chez les candidats, positionnés sur une VAE de 1er ou de 2ème cycle, consiste à produire rapidement un modèle fermé sur lui-même, peu évolutif, mais débouchant sur une solution, déclinée sous forme technique. On retrouve dans cette catégorie, des professionnels se décrivant comme des « Empiriques », amenés à produire dans l’urgence. Peu sensibilisés à la démarche de modélisation, ils la vivent comme un « mal nécessaire », éloignée de leur pratique professionnelle. Leur but prioritaire est de proposer une solution technique en s’appuyant sur des besoins recensés, peu ou pas interrogés. Le savoir faire réside principalement dans leur faculté de transformer des spécifications en lignes de codes. La compétence s’exprime prioritairement à travers cette maîtrise technique. Cette approche majoritairement technocentrée (Rabardel, 1995) minimise le rôle de l’utilisateur dans la conception qui est parfois sollicité pour amender ou valider le prototype. Destinataire du produit final, il n’occupe cependant pas un rôle central dans la démarche de conception.

38La deuxième stratégie (choix d’une solution par identification du problème), repérable chez les candidats positionnés sur une VAE de 2ème cycle ou ingénieur, consiste à construire le problème à travers un modèle, et ce, en interaction avec les besoins du client. Il s’attache alors à comprendre « de quoi s’agit-il ? Quel est le problème ? ». Vise à en cerner les contours, à produire une représentation avant d’envisager une solution. Il affine cette phase de construction en parcourant l’exploration des possibles, en identifiant les contraintes. Le professionnel sait à travers son expérience intégrer de nouvelles nécessités qui surviendront inévitablement. Au sein de cette deuxième population, nous pouvons affiner en faisant ressortir deux types de stratégies qui s’insèrent néanmoins dans une approche anthropocentrée (Rabardel, 1995), qui intègre pleinement dans la conception des « objets » l’activité des utilisateurs et vise à servir au mieux leur activité. Une stratégie quasi exclusivement centrée sur le client, pour s’assurer de recenser complètement les besoins avant d’aller plus avant dans le processus de conception. Elle consiste en un inventaire complet de ses besoins.

39L’autre procède d’une démarche itérative, qui s’attache à partir d’un prototype réalisé, à faire ressortir d’autres besoins, non exprimés spontanément. Dans cet esprit, le modèle ou le prototype de l’application vise à susciter des réactions, engager la discussion pour créer une dynamique facilitant l’émergence de besoins non repérés ou exprimés. Cependant, cette option d’un modèle récursif, exprime une certaine défiance affichée par les informaticiens vis-à-vis d’un client supposé d’emblée savoir. À l’encontre d’une étape, clairement située, d’extraction des besoins, la démarche itérative s’apparente davantage à une approche constructiviste. Il s’agit, par itération successive, en confrontant des points de vue (maître d’ouvrage, analyste, utilisateur...) de stabiliser progressivement un modèle, en passant par des « objets intermédiaires » définis comme des représentations externes mises en circulation au cours du processus de conception (Jeantet, Tiger, Vinck, & Tichkiewitch, 1996). La transformation de cette application en objet social nécessite que les représentations émanant des acteurs au sens large de la conception (utilisateur, client, maîtrise d’ouvrage,…) soient explicitées, détaillées, redéfinies, renégociées et enfin stabilisées. (Grosjean & Brassac, 1997).

40Les propos de ce candidat, faisant référence à une « réflexion service », renvoyant à l’ utilisateur illustrent le processus à l’œuvre « Ce dont je me suis rendu compte, c’est que je pensais objet tout en gardant une réflexion service, j’avais constamment un cheminement itératif, j’allais du service, ce que je veux obtenir, ce que je veux fournir, à comment je veux décomposer ce service en objets, en classes ; je faisais constamment un aller-retour… presque ce qui est visuel dans le service, même l’image, la fenêtre, l’application, inconsciemment, en fait, à chaque fois que j’avais un problème, je me disais, que veux-tu ? »

41Les besoins ne relèvent pas alors d’un seul recensement aussi minutieux soit-il (analyse « à la balayette » de Le Moigne), ou d’une démarche d’extraction qui présupposerait que le client en soit dépositaire, mais d’une activité de co-construction initiée par l’analyste. Elle s’exprime à travers les propos d’un candidat, qui affirmait la nécessité « de faire vivre les spécifications ». Elle renvoie également à l’idée que le produit de la conception (modèle, schéma, maquette,...) rétroagit sur les besoins, en étant susceptible de les faire évoluer. Le modèle est ainsi investi comme support de questionnement, qui tend à repousser la prise de décisions fermes, en attendant d’en cerner les contraintes. Cette phase de construction du problème, sur laquelle s’attardent volontiers les professionnels de notre échantillon que l’on qualifiera d’experts, fait ressortir des stratégies connectées à plusieurs buts. Qu’on ne se méprenne pas, les candidats « experts » développent aussi en tâche de fond, une « naturelle et irrépressible propension à penser solution dès le début de la conception » (Béguin & Darses, 1998). Ils évoquent ainsi volontiers des solutions développées lors de situations professionnelles proches, qu’ils sont tentés de transférer telles quelles. Cependant, ils prennent conscience, comme en témoigne ce candidat, des limites d’un transfert intégral d’une solution : « Mon principal problème, comme je suis officier chargé des sports, je suis amené à concevoir des applications de ce type, il ne fallait pas anticiper ces objectifs par rapport à ce que j’avais déjà réalisé, c’était surtout ne pas faire appel à ma mémoire pour redessiner l’équivalent… Je me suis projeté en essayant de rester maître de cette projection, en faisant table rase du problème en inventant mon propre problème, de retranscrire mon propre problème, il m’importait d’être chevillé au problème ». Ainsi, si la solution émerge rapidement par familiarité avec d’autres situations rencontrées, elle est mise en tension avec les besoins des utilisateurs dans la construction « d’un espace d’intersubjectivité » (Zarifian, 1996).

5.2. Des stratégies efficaces : la poursuite de plusieurs buts ou « concevoir en modélisant et… planifier en concevant »

42Nous observons que la production d’un modèle amène le concepteur à se poser des questions non spontanées ou qui auraient surgi plus tardivement dans le processus, obligeant un retour en arrière coûteux en temps. Elle oblige à s’arrêter à la phase de conception et soumettre une représentation de sa compréhension à l’utilisateur, avant de se précipiter vers une solution technique peu ou pas adaptée et ce, d’autant plus que la tâche à effectuer est complexe. Par ailleurs, les entretiens de confrontation effectués auprès de ces candidats permettent de relever au sein des images opératives (représentations dont le but est d’orienter l’action), un nombre variable de buts visés.

43Ce qui caractérise un professionnel « expert », est la capacité à poursuivre plusieurs buts, qui agencés selon des priorités variables traduisent des stratégies différenciées. Quand nous évoquons la poursuite de plusieurs buts, il nous faudrait être plus précis, en signalant chez certains candidats, la quasi-simultanéité des buts poursuivis (concevoir en intégrant conjointement des préoccupations organisationnelles) ou au contraire une intégration de buts principaux en sous buts hiérarchisés (on décline un modèle conceptuel « valide », qui questionne sur l’implémentation et les contraintes organisationnelles...). Cette mobilisation de plusieurs buts caractérise dans une démarche de conception, une adaptation à la complexité par l’entremise de la stratégie. Ainsi, un informaticien peut-il considérer l’exercice de modélisation comme une micro-action, incluse dans une macro-action qui renverrait à une conception complète intégrant toutes ses facettes (analyse, modélisation, développement, planification du projet, mise en test, implémentation, suivi et maintenance,…). Le professionnel « confirmé » serait celui qui a développé une vision intégratrice des nombreuses étapes qui accompagnent le processus de conception à son terme. Il s’agit de percevoir les incidences d’un choix en ayant développé un réseau de significations à portée « macro ». On observe l’émergence de modèles, mêlant simultanément de nombreux points de vue (fonctionnel, conceptuel, logique, physique,…). Il est important de rappeler qu’il ne s’agit pas, pour les professionnels expérimentés, de points de vue disjoints, mais emboîtés, intégrés, inter reliés.

44Le témoignage de ce candidat illustre ainsi nos propos : « Oui, dans ma tête je pense en tant que chef de projet, je fais la cartographie à ce niveau-là, puis je descends à un niveau études et cas, qui est la partie chaînage avec les opérationnels. Ces deux parties (modélisation et conception) sont liées parce que dans le problème, il y a 3 parties, dans le problème comme c’est posé, c’est la partie stratégique, maintenant, il reste la partie opérationnelle, la partie organisationnelle, je descends d’un cran et je passe à la partie opérationnelle dans mon triangle, j’ai la partie stratégique, le problème qui m’a été posé, comme je pense le solutionner, je donne des pistes aux opérationnels et derrière, ils vont coder en C++, en Java et apporter éventuellement des modifications, les grandes lignes pour bien préciser ma pensée ».

45Quand nous parlons de complexité, nous faisons allusion à une démarche qui tend à penser localement, en intégrant néanmoins des préoccupations globales. Cette vision périphérique déborde la seule tâche du moment pour embrasser du regard l’aval du processus de conception et faire émerger des contraintes de prime abord non repérées, ainsi que des ressources insoupçonnées. Le professionnel développe une pensée « avec une longueur d’avance » alors que le novice se limite à l’ici et maintenant avec l’objectif d’exprimer une solution au problème.

46Toutefois, si la multiplicité des buts contribue à enrichir l’image opérative, elle peut parfois la « brouiller », en faisant naître des conflits de positionnement (centration excessive sur telle phase du processus de conception au détriment de telle autre…). Elle se traduit par une complexification du modèle produit, et engage l’analyste à multiplier les représentations ou l’incite à une rupture qualitative de son système. Il peut alors, s’il dispose d’un langage d’une plus grande puissance d’expression, passer à un plus haut niveau d’abstraction.

5.3. Une typologie bâtie sur des stratégies différenciées

47Une typologie se déclinant en six types émerge à travers les buts poursuivis. Elle fait ressortir la prédominance de tel but, ainsi que leur intégration éventuelle en sous objectifs (e.g : on modélise pour mieux concevoir et planifier), renvoie aux deux approches évoquées que sont une centration privilégiée sur la construction ou sur la recherche quasi immédiate d’une solution au problème. Ajoutons que la position « construction du problème » nous est apparue très liée à une familiarisation avec la démarche de modélisation, sous tendue par la maîtrise d’un métalangage (UML, Merise,…). Il y a une tension créatrice entre le souci de décliner un modèle pragmatique (orienté de manière variable vers l’action) avec un langage susceptible de traduire le mouvement instable des besoins du client. Dit autrement, il s’agit de passer d’un univers informationnel informel à une représentation formelle en intégrant une vue commune aux utilisateurs et concepteurs. Se doter d’un langage pour faire émerger un modèle que l’on interroge, en le faisant évoluer à travers les contraintes et ressources repérées, c’est enrichir l’objet de la conception. Toutefois, le langage doit être au service de l’analyste, il est alors institué comme instrument « par le sujet qui lui donne le statut de moyen pour atteindre les buts de son action » (Rabardel, 1999). Cette appropriation relève d’un processus long et ardu, que la citation de Bakhtine (1978, p. 15) transposée pour notre propos, éclaire, nous semble-t-il particulièrement : « Le mot du langage, est un mot semi-étranger. Il ne le sera plus quand le locuteur y logera son intention, son accent, en prendra possession, l’initiera à son accent sémantique et expressive (...). Le langage n’est pas un milieu neutre. Il ne devient pas aisément, librement, la propriété du locuteur. Il est peuplé et surpeuplé d’intentions étrangères. Les dominer, les soumettre à ses intentions et accents, c’est un processus ardu et complexe. ». On note ainsi des intentions ou points de vue multiples (fonctionnels, structurels, ou physiques), inscrits dans certains modèles peu orthodoxes (en référence à une normalisation en vigueur) et ce dès le début de la conception.

  1. L’empirique /développeur produit dans l’urgence en faisant l’impasse sur le modèle ou en vivant cette phase de modélisation comme « un mal nécessaire ». Il s’attache alors à produire un modèle orienté principalement vers l’action immédiate et se focalise sur une application fermée sans la penser évolutive. Il éprouve également des difficultés à se projeter dans son modèle (Morand, 2004), à saisir ce qu’il représente effectivement, à être un support de dialogue. N’ayant pas fait l’objet d’une genèse instrumentale, la démarche de modélisation n’est pas une ressource pour penser efficacement son action, car s’avérant peu opérative. La démarche de conception est « figée » très rapidement, et rend difficile toute évolution de l’application.

  2. L’organisationnel (chef de projet) se centre sur les étapes du processus au détriment du modèle. Le modèle est délégué à un « conceptuel ». Une vision fonctionnelle prédominera et incitera l’analyste à se substituer à l’organisateur pour planifier les étapes. L’activité s’organisera autour du but dominant consistant à organiser un événement, à travers sa dimension temporelle déclinée « en avant », « pendant », « après ». On perd partiellement de vue la dimension technique de la commande, pour se plonger dans un projet, mobilisant des ressources humaines, des coûts, des durées. On retrouve fréquemment ce type de positionnement chez des chefs de projets, qui privilégient une démarche organisationnelle, centrée sur le bon déroulement du projet. La vision technique cède fréquemment le pas à des préoccupations économiques.

  3. Le scolaire/académique s’engage dans la modélisation en développant une visée épistémiques, déconnectée d’une pratique professionnelle. Son modèle est une traduction de l’énoncé proposé avec un formalisme logico-mathématique maîtrisé, dénué cependant de la vision d’un processus de conception ouvert. Le modèle produit reste un but et non un moyen pour penser le travail d’organisation et de conception ultérieur. Il est un décalque d’un énoncé tel qu’il a été appréhendé, mais pas ou peu orienté vers l’émergence d’un questionnement autour des besoins de l’utilisateur. Maîtrisant les signes, ce type de professionnel n’est pas en mesure de les faire parler, par défaut d’usage social.

  4. Le facilitateur/communicant (relation clients privilégiée) privilégie l’analyse des besoins en maîtrisant, voire en se méfiant de son background informatique. Il fait en sorte de ne pas impliquer prématurément son expérience, au risque de « biaiser » le recueil des besoins du client. Son expérience l’a mis en garde contre l’empressement à vouloir raccourcir cette première phase, au risque de produire une application dans laquelle le client ne se reconnaît pas. Il justifie d’une longue expérience qui l’a confronté à la prise en charge de nombreux projets. La position adoptée par ces professionnels vise à produire la meilleure anticipation du fonctionnement de l’homme et de son activité. Selon Béguin (2005), elle traduit, l’idée que tout « dispositif technique, tout artefact, mobilise durant sa conception, cristallise dans l’artefact et véhicule dans la situation de travail une connaissance, une représentation, et au sens le plus large un modèle de l’utilisateur, de son activité et de son travail ».

  5. Le chef de projet/technique privilégie la lisibilité du modèle pour le développeur en y intégrant des indications facilitatrices (pseudo-code, requête SQL, outil cible de développement), mais adopte une vision organisationnelle (planification des tâches). Les compétences techniques développées sur des fonctions antérieures (programmeur, analyste-programmeur) demeurent les référents majeurs qui guident l’action de ce professionnel. Il met à profit sa connaissance des contraintes ou des ressources rencontrées par les développeurs pour orienter le processus de conception. Le modèle produit fait office de balise, qui donne des repères et des cadres pour l’activité. Cependant, le répertoire des compétences techniques se voit réinvesti et profondément ré-élaboré pour répondre à des buts non plus seulement orientés directement vers la construction de l’application, mais aussi pour répondre à des buts pragmatiques (gestion d’un budget, management d’une équipe, relations et négociations avec le client,…).

  6. L’anticipateur/simulation privilégie un modèle à dominante « abstraite », prenant en compte la réutilisation, et opte pour une conception itérative. Il réalise un prototypage qui, soumis au client fait l’objet de modification par affinement. Il s’attache à anticiper les évolutions de l’application. Cette option consiste à anticiper non pas pour spécifier des solutions, mais pour laisser une certaine plasticité. Daniellou (2004) évoque l’anticipation « d’espaces d’activité future possibles » qui doivent néanmoins présenter des « frontières » pour guider l’opérateur.

48Les types 5 et 6 utilisent la modélisation comme un marchepied permettant de porter un regard sur l’activité de conception. On observe une forte connexion entre les activités de modélisation et de conception. Bien évidemment, dans ces dernières catégories on relève un niveau d’efficience variable : le recours à la réutilisation à travers la création de classes abstraites, la pertinence à informatiser, différencient significativement les candidats. Les modèles produits par ces professionnels ne se valent pas évidemment, leur comparaison fait appel à plusieurs registres. Ainsi, certains modèles sont à la fois plus explicites et plus « riches » que d’autres, semblent ne pas rester à la surface des choses. Enfin, le modèle produit dans ce contexte de conception ne peut être qualifié de faux ou de vrai, mais de plus ou moins bon.

6. Quels retombées et enseignements pour la VAE ?

49En resituant cette démarche de modélisation au sein de la VAE, nous avons mis en relation les demandes exprimées par les candidats, les résultats des jurys et la qualité du modèle produit. Ainsi, avions nous fait l’hypothèse d’un lien fort entre la richesse du modèle produit, le type de demande exprimé par le candidat et le niveau de validation accordé par le jury. S’il n’est pas aisé de définir qualitativement un modèle « riche », voici les critères que nous avons retenus :

  • Il est intégré en tant qu’instrument pour l’action, support de dialogue avec soi et les autres, désignés comme co-concepteur (client, usagers, développeur,…).

  • Il dénote la maîtrise d’un langage facilitant une représentation de l’ensemble du domaine concerné.

  • Il est investi de plusieurs buts, exprimés en général à travers la multiplicité de schémas (organisationnel, conceptuel, physique,..).

  • Il reflète assez explicitement une image opératoire, que l’on appréhende cependant plus finement à travers l’autoconfrontation.

  • Il est une description informée, variable en largeur (signifiant les étapes ultérieures) aussi bien qu’en profondeur (précision et niveau d’abstraction).

  • Il vise à réduire l’implicite dans une démarche de conception.

  • Il est en mesure au fil du processus de faire ressortir les procédés d’augmentation et de diminution de l’information. On l’observe à travers les différentes versions du modèle ou d’après les retouches qui accompagnent la conception.

50Sans que nous ayons procédé à une étude statistique basée sur des corrélations, nos résultats attestent d’une forte concordance entre la « richesse » du modèle et le niveau de validation obtenu. On constate ainsi que les candidats ayant produit un modèle centré sur une solution technique qui ne prend pas en compte les besoins des utilisateurs, obtiennent une validation de 1ere cycle universitaire. Plus le modèle traduit l’intégration de buts multiples, plus la validation se situe à un niveau élevé. Un regard différencié (technique, gestionnaire, humain) permet d’appréhender un objet sous différentes facettes pour en penser les articulations adossées à l’analyse des besoins. Cette dernière, dans sa fonction d’initier et de guider guide l’action, est pensée par les professionnels experts, comme une force « d’appel et de rappel ».

51On notera également que les trois composantes (technique, gestionnaire, communication) enseignées dans de nombreuses écoles d’ingénieur sont valorisées par les milieux professionnels. On observe assez fréquemment une prise de distance marquée vis-à-vis de la technique, qui semble caractériser bon nombre d’ingénieurs en France. Ce décalage, entre une solide formation technique enseignée dans les écoles et l’exercice d’un métier, n’est pas sans questionner le recours parfois réducteur au référentiel de formation (compétences), utilisé dans le cadre d’une VAE. L’utilisation d’une tâche de modélisation, permet non seulement de mettre à jour la richesse d’expériences professionnelles, mais également de questionner la pertinence de certains référentiels, insuffisamment imprégnés de la réalité professionnelle. Ainsi, une vision qui poserait non pas un regard pointilliste mais global sur l’expérience, se doit non seulement d’en saisir la dynamique et l’organisation, mais également son évolution au sein d’un champ professionnel. Cette dernière préoccupation permet de combler le décalage entre la vision universitaire, centrée parfois trop exclusivement sur le référentiel, et l’évolution d’une fonction aux prises entre de multiples tensions prescriptives au sein de contextes professionnels.

52Précisons toutefois que pour deux candidats engagés dans une validation totale du diplôme d’ingénieur, le jury a prescrit de reprendre une partie du cycle d’études. L’examen de ces rejets, nous semble à plus d’un titre instructif.

53Si l’expérience de ces candidats apparaît dense (postes tenus, projets mis en avant, évolution de carrière…), ils ont toutefois éprouvé de grosses difficultés à passer du registre déclaratif au registre explicatif. Il s’agit dans le cadre de la démarche VAE de dépasser la simple énumération de projets ou réalisation, pour s’engager dans une démarche d’explicitation de « comment j’ai fait ce que je valorise dans mon dossier ». Ces mêmes candidats ont produit des modèles qui semblent parler pour eux, tout en étant assez hermétiques pour l’extérieur, et éprouvent une grande difficulté à transmettre. Nous avons pointé une certaine inhibition à communiquer à autrui et à opérer un retour réflexif sur soi dans le cadre de la réalisation de leur dossier. Une conception restrictive de la compétence assimilée à la performance (Savoyant, 1999), pourrait questionner éventuellement la décision du jury pour ces deux candidats. Toutefois, la VAE, en tant que démarche de communication d’expérience, peut amener certains candidats à inscrire leur argumentaire à travers des attentes présumées du jury. En configurant exagérément leur expérience à ces attendus, ils prennent le risque de la dénaturer et ne présenter que ce qui leur semble socialement valorisable. Cet écueil, plutôt que s’attacher à lever les implicites propres à l’activité en adoptant un regard réflexif, peut égarer le candidat dans deux directions. Soit, il met en avant un savoir académique, déconnecté de sa pratique, soit il affiche des réalisations en guise de preuves qui ont vocation à parler d’elles-mêmes. Dans ces deux cas, il passe à côté de l’essentiel à savoir faire ressortir explicitement l’organisation de son activité. Pour sortir de cette ornière, nous suggérons un retour à l’activité commentée, par l’entremise du modèle.

Une professionnalité qui transforme le modèle cognitif

54Notre étude fait ressortir que l’appropriation par des professionnels d’un instrument, vise à le détourner en partie de son objectif d’utilisation initiale. Processus de catachrèse, le modèle ainsi élaboré remplit d’autres fonctions et déborde la seule mise en (re)présentation de phénomènes/signes. Le modèle opératif du professionnel n’a pas ou peu de visée épistémique, il se projette sur un support (appelé indifféremment diagramme, schéma, modèle) pour orienter l’action. On peut ainsi dire que la professionnalité ne se rajoute pas au modèle cognitif, mais le modifie. Ainsi, le modèle opératif qui est sous-jacent à l’organisation de l’activité est une transformation profonde des simples connaissances (modèle cognitif) mobilisées par le sujet. Autrement dit, les acteurs utilisent un langage, mais la maîtrise de ce langage ne dit pas tout de l’organisation réelle de l’activité.

55On peut interpréter le processus de construction d’un modèle opératif à l’aide de la théorie de la genèse instrumentale de Rabardel : les acteurs utilisent un instrument langagier, mais ce n’est au départ qu’un artefact et tout leur travail consiste à se l’approprier suffisamment pour en faire leur instrument.

56À ce titre, le modèle opératif traduit autant l’activité à l’œuvre que la place du professionnel doté de préoccupations, dans le process de production. (Développeur, chef de projet technique, chef de projet managérial,…). Certains modèles laissent transparaître des difficultés de positionnement, perceptibles à travers la valorisation de tel but au détriment d’un autre, étranger ou éloigné de ses fonctions. Ainsi, tel chef de projet nostalgique par rapport à son ancienne fonction de développeur, créera un modèle très technique.

7. Conclusion

57D’après Ughetto (2004), « la compétence serait une capacité à traduire un problème ou une démarche exposée par le client en solution qui ne devient envisageable que parce qu’une expertise (…) permet de reformuler la question posée par le client en des termes susceptibles de donner lieu à une solution ». Nous sommes tentés d’ajouter non seulement reformuler mais faire évoluer, voire susciter des besoins à venir. Engagé dans une activité de décodage du monde réel, orienté en cela par les besoins du client, le professionnel s’appuie sur l’utilisation d’un langage pour générer in fine un code source. Ainsi, la compétence consisterait en la quête du modèle opératif du client qui contribue à faire émerger chez l’informaticien, à travers l’enrichissement de son propre modèle opératif, l’artefact doté des fonctionnalités en adéquation avec les vues des utilisateurs. Plus l’artefact applicatif sera proche de son modèle opératif, plus aisément cet artefact se transformera en instrument pour le client. Ce mouvement d’appropriation spécifique du concepteur, s’illustre par cette anecdote omniprésente chez les professionnels : « notre métier est très difficile, car il nécessite de maîtriser deux métiers : le nôtre et celui du client ». Cette capacité s’actualise lors du processus de conception au sens large du terme. On peut faire l’hypothèse d’une expérience riche que l’on qualifierait de polysémique, intégrant un dialogue à plusieurs voix (client, développeur, chef de projet,..) qui est justement l’objet de la VAE.

58Ainsi, plus les informaticiens sont-ils en mesure de passer d’un système sémiotique à un autre, relayé par le questionnement, plus sont-ils susceptibles de développer une représentation riche, et donc une application « ouverte ». Une réalité ne devient objet d’expérience en informatique que si elle possède une structure de signe réinscriptible dans le médium informatique.

59Toutefois, on ne peut réduire « l’intelligence de la tâche » (Montmollin, 1986) au seul modèle produit par ces professionnels. L’activité déborde largement le modèle, qui toutefois nous permet d’en inférer certaines caractéristiques.

60Revenons alors sur les dossiers de VAE, en nous demandant ce que notre recherche peut apporter pour les améliorer. On a remarqué que les dossiers habituels de VAE s’inscrivaient dans un paradoxe : ils cherchent à donner à voir (et évaluer) un « faire » par le truchement d’un « dire ». Ce dire du faire est au fond la seule manière de rendre compte de l’expérience acquise, si on veut éviter les épreuves de type concours, examen ou test. Il a le grand avantage de donner à voir l’expérience d’un acteur dans sa durée. Mais il risque d’être toujours soupçonné d’un écart entre le faire et le dire du faire. L’apport principal de la présente recherche ne consiste pas à mettre l’accent sur le « faire », mais sur l’analyse de celui-ci. Car il existe une différence forte entre la description d’une activité et l’analyse de celle-ci. Le cadre théorique que nous avons utilisé, structure conceptuelle, identification des stratégies, permet, nous semble-t-il, de mener de façon rigoureuse une analyse de l’activité des acteurs. Il faudrait que les candidats VAE, en constituant leur dossier, puissent opérer un déplacement semblable : passer d’un récit des expériences qu’ils ont vécues à une analyse des moments significatifs qui peuvent attester des compétences qu’ils ont alors acquises. On verrait alors que construire un dossier de VAE comporte aussi, peut-être même surtout, une dimension de formation personnelle, car l’analyse de sa propre activité nous paraît être un vecteur de développement. Enfin, la démarche de modélisation nous semble pouvoir introduire un « espace de confrontation » entre le candidat et les membres du jury. Ainsi, une plus grande familiarité avec une tâche professionnelle rapproche l’évaluation de l’exercice du métier, tout en offrant un regard inédit de leur propre implication.

61Elle atténue probablement les rapports de domination implicites, d’autant plus agissant que le candidat est éloigné de la culture universitaire (Cherqui-Houot, 2006).

62Cette option, sans présumer des difficultés de mise en place, nous semble assez prometteuse. Au-delà de l’objectif d’évaluation, elle favoriserait un processus dialogique d’apprentissage mutuel (Hatchuel, 1996, Béguin, 2004) susceptible de faire évoluer le regard sur l’activité de travail, voire de dissiper des incompréhensions de part et d’autre…

Haut de page

Bibliographie

Astier, I. (2008). Ecriture de soi, une injonction réflexive. L’exemple de la Validation des Acquis de l’Expérience. Sociologie et sociétés, XL(2), 51-68.

Aubret, J. (2003). La validation des acquis de l’expérience. Savoirs, n° 1, 57-66.

Astier, P. (2001). La communication de l’expérience professionnelle : éléments d’analyse de l’activité d’un sujet. Thèse de sciences de l’éducation, Paris, CNAM.

Bakhtine, M. (1934/1975/1978). Esthétique et théorie du roman. Paris : Gallimard.

Barbier, J-M., & Galatanu, O. (2004). Les savoirs d’action : une mise en mot des compétences ? Paris : L’Harmattan.

Béguin, P., & Darses, F. (1998). Les concepteurs au travail et la conception des systèmes de travail : Points de vue et débats. Actes du colloque Recherches et Ergonomie.

Béguin, P (2004). L’ergonome acteur de la conception. In P. Falzon (Ed.) Ergonomie (pp. 375-390). Paris : PUF.

Béguin, P. (2005). Concevoir pour les genèses professionnelles. In P. Rabardel, & P. Pastré (Eds), Modèles du sujet pour la conception (pp. 31-70).Toulouse : Octarès.

Benhamou, A.-C. (2005). La validation des acquis de l’expérience en actes. Rapport de mission. Ministère de l’Éducation Nationale, de l’enseignement supérieur et de la recherche.

Bouleau, N (1999). Philosophie des mathématiques et de la modélisation, du chercheur à l’ingénieur. Paris : L’Harmattan.

Cherqui-Houot, I. (2006). VAE : les universités à l’épreuve de l’expérience. Savoirs, n° 10, 93-110.

Clot, Y, Prot, B. (2003) Expérience et diplôme : une discordance créatrice. L’orientation scolaire et professionnelle, 32(2), 183-201.

Cuvillier, B. (2004). La VAE : un tremplin pour la formation ? Education Permanente, 158, 127-140.

Cuvillier, B., & Faudiere, L. (2009). La rencontre avec le jury : vécu et ressenti des candidats à la VAE. Relief du CEREQ, n° 28, octobre 2009.

Daniellou, F. (2004) : Ergonomie dans la conduite de projets de conception de systèmes de travail. In P. Falzon (Ed.), Ergonomie (pp. 359-373). Paris : PUF.

Détienne, F. (1998). Génie logiciel et psychologie de la programmation. Paris : Hermès.

Feutrie, M. (2003). La mise en œuvre de la VAE : vers un débat de société ? Actualité de la formation permanente, n° 182, 29-37.

Feutrie, M. (2004). Une autre évaluation, une autre validation pour l’expérience. Education permanente, 158, 99-114.

Grosjean, S., & Brassac, Ch. (1997). L’émergence de l’objet : de l’objet cognitif à l’objet social. Cinquième table ronde francophone sur la conception, 01DESIGN’97. Théoule-sur-Mer, 25 septembre.

Hatchuel, A. (1996). Coopération et conception collective. Variété et crises des rapports de prescription. In G. de Terssac, & E. Friedberg (Eds.), Coopération et conception (pp. 101-122). Toulouse : Octarès.

Jeantet, A., Tiger, H., Vinck, D., & Tichkiewitch, S. (1996). La coordination par les objets dans les équipes intégrées de conception de produit. In G. de Terssac, & E. Friedberg (Eds.), Coopération et conception (pp. 87-100). Toulouse : Octarès.

Lainé, A. (2005). VAE, quand l’expérience se fait savoir. L’accompagnement en validation des acquis. Paris : Erès.

Levy, P. (1991). L’idéographie dynamique. Vers une imagination artificielle ? Paris : La Découverte.

Liétard, B., & Merle, V. (2004). La reconnaissance, un nouvel espace de formation ? In P. Carré, & P. Caspar (Eds.), Traité des sciences et techniques de la formation (pp. 531-551). Paris : Dunod.

Mayen, P. (1999). Des situations potentielles de développement. Education Permanente, 139, 65-86.

Mayen, P. (2006). Evaluer avec l’expérience. In G. Figari, & L. Mottier-Lopez (Eds.) Recherche sur l’évaluation en éducation (pp. 25-33). Paris : L’Harmattan.

Merle, V. (2005). L’expérience est source d’apprentissage. In Reconnaissance des acquis de l’expérience. Apports d’une réflexion internationale. Discours introductif aux journées d’échanges organisées par la commission française pour l’UNESCO.

Montmollin de, M. (1986). L’intelligence de la tâche. Berne : Peter Lang.

Morand, B (1995). Statut épistémologique des modèles en conception des systèmes d’information. Revue Ingénierie des Systèmes d’information, Hermès, 3(5/1995), 665-700.

Morand, B. (2004). Logique de la conception. Paris : L’harmattan

Nicole (2004). Expériences modélisatrices dans les pratiques et les langages informatiques de modélisation. In F. Lerbet-Sereni (Ed.), Expériences de modélisation, modélisation de l’expérience (pp. 45-66). Paris: L’Harmattan.

Norros, L. & Nuutinen, M. (2002). The core-task concept as a tool to analyse working practices. In N. Boreham, R. Samurçay, & M. Fischer (Eds.). Work Process Knowledge (pp. 25-39). London : Routledge.

Olry, P. (2004). Saisir son expérience lors d’une VAE : l’auto-analyse du travail en perspective. Education permanente, 159, 37- 49.

Pastré, P (1997). Didactique professionnelle et développement. Psychologie française, 42(1), 89-100.

Pastré, P. (1999). La conceptualisation dans l’action : bilan et nouvelles perspectives. Education permanente, 137, 13-37.

Prot, B. (2002). La validation des acquis au milieu du gué. Le point sur l’expérience professionnelle. Bulletin d’information des CPC, n° 34, 19-25.

Rabardel, P. (1995). Les hommes et les technologies. Approche cognitive des instruments contemporains. Paris : Armand Colin.

Rabardel, P. (1999). Le langage comme instrument ? Eléments pour une théorie instrumentale élargie. In Y. Clot (Ed.), Avec Vygotski (pp. 241-265). Paris : La dispute.

Rivoire, B. (2004). VAE : par quel détour passe l’évaluation ? Education permanente, 159, 79-90.

Rivoire, B. (2006). VAE. Un « accompagnement » du candidat... De quoi parle t-on ? Pourquoi ? Expérimentation d’une « pratique réflexive » d’accompagnement. Paris : CNAM/Institut MCVA et UNIFAF.

Savoyant, A. (1999). Compétence, performance, activité, Entreprise et compétences : le sens des évolutions. Association Ecrin.

Terssac de, G., Frieberg, E. (1996). Savoirs, compétences et travail, In J.-M. Barbier (Ed.), Savoirs théoriques et savoirs d’action (pp. 223-248). Paris : PUF.

Ughetto, P. (2004) L’économique au coeur du travail salarié. Renouvellements paradigmatiques en sociologie du travail. Histoire et Sociétés, n° 9, janv., 30-41.

Vygotsky, L. (1934/1997). Pensée et langage (Trad. F. Sève) (3ème édition). Paris : La dispute.

Volle, M. (2005). Une méthode de modélisation informatique avec UML. JDN (Journal du Net) [consulté le 13/09/07 à l’adresse suivante : http ://www.journaldunet.com/solutions/0503/050322_chro_bpms.shtml ]

Zarifian, P. (1996). Travail et communication. Essai sociologique sur le travail dans la grande entreprise industrielle. Paris : PUF.

Haut de page

Annexe

Caractéristiques de la population

Diplôme visé

âge

Durée expérience

spécialité

Fonction occupée

au moment de la VAE

Niveau de formation

initiale

Taux de validation

obtenu

1

DUT

42

13 ans

Adjoint au directeur informatique

Bachelor of Business Administration

20 %

2

DPCT*

38

6 ans 1/2

Ingénieur recetteur

Niveau 4 AFPA + 2 valeurs de maths info

70 %

3

DPCT

36

8 ans

Chef de projet

Bac S

100%

4

DPCT

27

5 ans

Développeur. Chef de projet

Maths sup.

Niveau DUT

100 %

5

DEST**

38

12 ans

Concepteur

DESS LEA

90 %

6

DEST

31

11 ans 1/2

Ingénieur développement

Niveau DUT GEII

70 %

7

DEST

36

11 ans

Gérant société

Analyste-programmeur

Cycle préparatoire ingénieur. DUT informatique

70 %

8

DEST

45

21 ans

Ingénieur développement

Bac C

50 %

9

DEST

35

11 ans 1/2

Chef de projet

BSAT (bac +2 en informatique délivré par l’armée de terre)

80 %

10

DEST

35

8 ans

Consultant et ingénieur

DUT informatique

50 %

11

DEST

35

7 ans

Architecte/développeur

DUT Biologie

70 %

12

DEST

32

8 ans

Ingénieur/chef de projet

BTS informatique

90 %

13

DEST

31

6 ans

Ingénieur conseil.

Bac S

Niveau Deug scientifique

80 %

14

DEST

33

5 ans

Développeur

Licence de maths. BTS informatique

90 %

15

DEST

30

6 ans

Développeur

Niveau Bac + 2

En informatique

Dépôt différé

16

DEST

31

5 ans

Animateur formateur de techniques éducatives

BAC C, math sup., DPCT informatique

50 %

17

DEST

29

7 ans

Développeur/chef de projet

Niveau BAC + 2 en informatique

60 %

18

DEST

41

18 ans

Directeur technique

1ère année de DEUG A

Formation professionnelle privée

Pas de dépôt

19

DEST

41

16 ans

Chef de projet (pompier de Paris)

DPCT + partie du DEST

100 %

20

ingénieur

28

5 ans 1/2

Ingénieur et chef de projet

Cycle complet ingénieur informatique sans validation

20 %

21

ingénieur

44

20 ans

Consultant, architecte SI

Niveau Bac+ 2

en informatique

20 %

22

ingénieur

41

12 ans 1/2

Chef de projet

Dess électronique, DEA télécom, DSG

100 %

23

ingénieur

37

14 ans

Responsable logiciel

BTS info. Industrielle

DU (bac + 3) info.industrielle

90 %

24

ingénieur

44

18 ans

Responsable tests dans un magazine professionnel informatique

1er cycle dentaire

60 %

25

ingénieur

33

10 ans

Ingénieur développement

Licence

Niveau maîtrise informatique

20 %

26

ingénieur

38

15 ans

Ingénieur développement

Dess mathématiques appliquées.

100 %

27

ingénieur

43

20 ans

Ingénieur système

DUT informatique

100 %

28

ingénieur

50

26 ans

Ingénieur développement

BTS électronique

DEST informatique

100 %

29

Ingénieur

47

13 ans

Chef de projet

BTS Biologie

Formation professionnelle AP et chef de projet

20 %

30

Ingénieur

41

19 ans

Chef de projet

DUT informatique +

2 valeurs Cnam

90 %

31

Ingénieur

38

15 ans

Chef de projet Manager

BTS informatique de gestion

10 %

32

Ingénieur

34

8 ans

Ingénieur Réseaux

DUT Génie mécanique

90 %

33

Ingénieur

50

25 ans

Ingénieur développement

3ème cycle universitaire

Pas de dépôt

34

Ingénieur

39

14 ans

Ingénieur Réseaux

DUT informatique +

2 valeurs Cnam

100 %

35

Ingénieur

49

25 ans

Ingénieur

BTS électronique

Niveau 2 de l’AFPA

20 %

* Le DPCT ou Diplôme de Premier Cycle Technique est un diplôme homologué de niveau III (Bac + 2), délivré par le CNAM.
** Le DEST ou Diplôme d’Etudes Supérieures Technique est un diplôme homologué de niveau II (licence, maîtrise), délivré par le CNAM.

La tâche d’analyse d’un problème

L’organisateur d’une course à pied souhaite développer une application informatique lui permettant de :

  • Gérer l’inscription des coureurs en distinguant plusieurs catégories (classes d’âge : senior, vétéran 1, vétéran 2, vétéran 3) ainsi que le sexe,

  • Éditer les dossards,

  • Gérer les temps de course des concurrents et éditer un classement général, par catégories et par sexe,

  • Disqualifier un coureur ou appliquer une pénalité,

  • Organiser la pasta-party (repas précédant la course) ouverte aux coureurs et conjoints.

  • Établir un contact avec :

    • Le service voirie pour assurer le fléchage du parcours et le nettoyage de la chaussée à l’issue de l’épreuve,

    • La sécurité routière pour régler la circulation, sécuriser certains passages,

    • L’assistance médicale qui se décompose en 2 services :

      • porter les premiers secours en cas de » petite » défaillance (Croix rouge) ou évacuer un coureur si son état le nécessite (Samu)

      • Les stands d’approvisionnement pour l’alimentation « liquide » ou solide.

Après analyse de ce problème, veuillez faire une modélisation, en faisant ressortir les différentes étapes de votre cheminement intellectuel. Vous justifierez vos choix.

Haut de page

Notes

1 Validation des Acquis de l’Expérience : Loi de modernisation sociale du 15 janvier 2002.

2 CNAM : Conservatoire National des Arts et Métiers

3 PRC : Point Relais Conseil, CIO : Centre d’Information et d’Orientation

Haut de page

Pour citer cet article

Référence électronique

Bruno Cuvillier, Gérard Canesi et Pierre Pastré, « Modélisation, faire et dire du faire pour des informaticiens engagés dans une démarche de VAE »Activités [En ligne], 7-1 | avril 2010, mis en ligne le 15 avril 2010, consulté le 15 janvier 2025. URL : http://0-journals-openedition-org.catalogue.libraries.london.ac.uk/activites/2317 ; DOI : https://0-doi-org.catalogue.libraries.london.ac.uk/10.4000/activites.2317

Haut de page

Auteurs

Bruno Cuvillier

Université de Lyon 2 (GRePS : Groupe de Recherche en Psychologie Sociale, EA : 4163)
bruno.cuvillier@univ-lyon2.fr

Articles du même auteur

Gérard Canesi

Conservatoire National des Arts et Métiers (CEANTE : Centre d’Etudes et d’Applications des Nouvelles Technologies)
gerard.canesi@cnam.fr

Pierre Pastré

Chaire de communication didactique au CNAM
pastre.pierre@wanadoo.fr

Articles du même auteur

Haut de page

Droits d’auteur

CC-BY-NC-ND-4.0

Le texte seul est utilisable sous licence CC BY-NC-ND 4.0. Les autres éléments (illustrations, fichiers annexes importés) sont « Tous droits réservés », sauf mention contraire.

Haut de page
Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search