Navigation – Plan du site

AccueilNuméros4Compte rendu d'innovationRetour d’expérience sur l’enseign...

Compte rendu d'innovation

Retour d’expérience sur l’enseignement de l’ingénierie système

Feedback on the teaching of system engineering
Erfahrungsbericht über das Unterrichten des Systems Engineering
Retrospectiva de experimento sobre la enseñanza de ingeniería de los sistemas
Philippe Meyne
p. 197-214

Résumés

L’introduction de l’enseignement de l’ingénierie système ne peut se faire selon des méthodes classiques à cause de la nature de cette discipline. Cet article expose la problématique et les solutions retenues pour insérer cet enseignement en première année du cycle ingénieur.

Haut de page

Texte intégral

Introduction

  • 1 La DGA est notre instance de tutelle. Cependant, elle intervient ici comme opérateur industriel.

1L’introduction de l’ingénierie système dans l’enseignement du cycle ingénieur de l’ENSTA ParisTech est la conséquence d’une demande institutionnelle forte de la part des industriels et de la direction générale de l’Armement (DGA)1. La réponse apportée a été la création d’une filière ingénierie système en troisième année. Pour faciliter le choix de cette filière par les étudiants, une semaine d’initiation à l’ingénierie système a été envisagée en première année. Cet article décrit l’ingénierie pédagogique conduite pour concevoir cette semaine d’initiation.

2Dans une première partie, je donne quelques définitions à propos de l’ingénierie système. Ces définitions, une fois posées, permettent de mettre en évidence les questionnements pédagogiques liés à cette discipline et dont les réponses sont données dans la seconde partie. Enfin le dispositif est décrit dans la dernière partie. Ainsi le lecteur pourra, à travers ce retour d’expérience, envisager la problématique de ce type de discipline et les solutions pédagogiques innovantes afférentes à ce domaine.

1. Qu’est-ce que l’ingénierie système ?

3L’ingénierie système est née de la nécessité, pour mener de grands projets, d’utiliser des méthodes rationnelles. Elle s’enracine dans l’histoire de la pensée à travers Descartes et son Discours de la Méthode (Descartes, 1637). Cependant, elle émerge à la suite des projets d’envergure menés par la NASA pour l’exploration spatiale et aussi à travers des grands projets tant civils que militaires, en particulier dans le domaine maritime, un sous-marin étant encore aujourd’hui considéré comme l’objet le plus complexe à concevoir. De manière concomitante, l’apparition de l’informatique et la complexité croissante de ses systèmes qui mélangent une vision hardware et software, ont conduit à formaliser des méthodologies cohérentes pour le développement, la maintenance et même le démantèlement d’architecture. La rencontre du monde industriel des « grands projets » et du monde informatique considérés comme des systèmes complexes donne aujourd’hui une discipline qui s’impose sous le nom d’ingénierie système.

4Aujourd’hui, les domaines d’application de l’ingénierie système se structurent toujours autour du spatial et des programmes militaires mais diffusent de plus en plus vers les transports, l’énergie, la production industrielle et bien d’autres encore.

5L’ingénierie système est portée au niveau international par l’International council on systems engineering (INCOSE). Elle est organisée en chapitres. Le chapitre français est l’Association française d’ingénierie système (AFIS).

1.1 Une définition de l’ingénierie système

6À l’opposé d’une vision empirique, l’ingénierie système se définit comme une démarche méthodologique coopérative interdisciplinaire et rigoureuse. Elle englobe toutes les activités indispensables pour concevoir, développer, faire évoluer et vérifier l’ensemble des processus et compétences humaines apportant une solution économique et performante aux besoins à l’origine de la démarche (AFIS, 2009)

7Elle s’appuie sur le concept de « système », défini ci-dessous, et la notion de « besoin ». La démarche prend sa source dans la définition d’un besoin exprimé et défini par l’ingénierie des exigences.

1.2 Qu’est-ce qu’un système ?

8Un système est un dispositif de tout ordre qui est envisagé selon trois approches : « boîte noire », « boîte blanche » et « fonctionnement ».

9L’approche « boîte noire » considère le système comme un tout qui répond à une finalité et qui interagit avec son environnement. Cette interaction s’effectue principalement par des échanges de flux sous forme de matières, d’énergies ou d’informations. En somme, cette approche considère la « boîte noire » comme un objet qui a pour fonction de transformer des flux entrants en flux sortants. Il est alors considéré uniquement à travers ces flux.

10L’approche « boîte blanche » consiste à ouvrir la boîte noire et à envisager l’architecture du système comme une structure à créer, à faire évoluer ou à démanteler.

11L’approche « fonctionnement » analyse comment le système interfère avec son environnement dans le temps. Cette approche conduit à comprendre l’évolution du système et son mode de pilotage.

1.3 L’objet de l’ingénierie système

12L’objet de l’ingénierie système est la conception du système comme répondant à une finalité définie. La conception en ingénierie système est une conception itérative. Un système est considéré d’abord comme un système de systèmes. Cette conception revient à structurer une architecture, à concevoir chaque sous-système, à les valider puis assembler et valider l’ensemble. Elle diffère du management de projet dans la mesure où celui-ci ne s’intéresse pas aux aspects techniques et scientifiques du projet mais juste à son organisation. L’ingénierie système englobe le management du projet (projet qui en lui-même est considéré comme un système), la conception du système et des produits contributeurs destinés à la conception, la modélisation et le démantèlement du système.

2. Ingénierie système et pédagogie

13L’adhésion des apprenants à une discipline comme l’ingénierie système se heurte à l’ambition même de ce type d’enseignement. L’objectif d’un module d’ingénierie système est d’apporter des savoirs, savoir-faire et savoir-être permettant aux apprenants de structurer leur méthode de travail pendant leur vie professionnelle et cela à plusieurs niveaux : débutant, confirmé, expert. Or l’utilité de ces savoirs n’est pas a priori une évidence. L’accès à la vie professionnelle pour les élèves de première année d’école d’ingénieur est une perspective encore lointaine. L’acquisition de ces savoirs n’apporte pas de satisfactions immédiates. Le cours de mathématiques est utile pour valider le module de mathématiques mais aussi pour suivre le module de physique, de mécanique, etc. Le profit du cours de mathématiques est, en conséquence, direct. Quid de celui de l’ingénierie système ?

14La mise en évidence de l’utilité des concepts d’ingénierie système est un axe de réflexion pour la mise en place de ce module. Elle est une condition pour que les apprenants adhèrent et se sentent motivés pour cette discipline.

15Condition nécessaire mais pas suffisante, car un second écueil existe. Un savoir ne se justifie pas de lui-même. Il faut qu’il soit institué et sous-tendu par un formalisme scientifique qui le justifie. Le formalisme de l’ingénierie système est juste sémantique. Les processus qui la constituent ont été construits en utilisant les bonnes pratiques de conception. Il existe des tentatives de formalisme plus structuré, basées sur une approche modèle avec une optimisation éventuelle mais, au niveau où se situe l’enseignement, il semble difficile d’introduire ces notions complexes dans le temps qui a été imparti. En conclusion, un processus ne se démontre pas, il se justifie par la pratique. Il faut en apporter la preuve.

16L’approche pédagogique est donc plus complexe que pour une discipline classique. Il en va de même pour d’autres disciplines à caractère transversal comme le « management de projet » ou l’« innovation ». L’acquisition des compétences ainsi que leur maîtrise passe plus par l’expérience personnelle que par la transmission classique professeur/apprenant.

17Enfin, l’ingénierie système n’est pas une discipline académique reconnue ; il y a peu d’enseignants-chercheurs capables de concevoir et d’animer des modules sur ce sujet.

18La plus mauvaise démarche serait de prendre la table des matières d’un ouvrage de référence comme Découvrir et comprendre l’ingénierie système (AFIS, 2009) et d’en faire son plan de cours. Il faut donc faire preuve d’innovation pédagogique et se donner les outils conceptuels pour ce faire.

2.1 Transposition didactique de l’ingénierie système

19La transposition didactique au sens défini par Michel Verret (1975) et étendu par Yves Chevallard (1991) est la conséquence de l’adaptation à des situations d’enseignement des savoirs ayant cours dans la société. Cette adaptation se fait de manière consciente ou non et de manière formelle ou non. Il s’agit d’une question centrale lors de la mise en place d’une innovation pédagogique. La caractérisation des conséquences d’une transposition didactique permet de déterminer les objectifs d’une ingénierie pédagogique d’un module.

20Pour l’ingénierie système, les savoirs ayant cours dans la société sont portés par l’industrie (DGA, Thalès, EADS et des PME de conseil) et par l’INCOSE via l’AFIS. À l’autre bout de la chaîne, il n’y a rien ou presque. L’émergence récente de l’ingénierie système fait qu’il n’existe pas de référentiel pédagogique. Il faut donc tout construire. Cette construction est l’objet de l’ingénierie pédagogique du module. Elle doit tenir compte des écueils inhérents à une transposition mal gérée. Une transposition didactique induit une distance entre le savoir d’origine et l’apprentissage de l’apprenant. L’apprentissage, c’est-à-dire, les acquis à l’issue du module, doit être perçu comme utile à l’exercice du métier futur. Il convient donc que la distance entre le savoir et l’apprentissage soit la plus faible possible pour qu’il soit directement transposable dans une situation réelle. La minimisation de cette distance constitue une bonne réponse aux difficultés décrites en introduction : utilité et preuve.

21Il existe d’autres écueils comme la mauvaise gestion de la construction préalable des apprenants. L’ingénierie système peut aller de soi pour un apprenant, il suffit d’un peu de bon sens. Ses expériences précédentes l’ont souvent conduit à ne jamais interroger la méthode de résolution de problème. Il a fait confiance à ses maîtres et à son bon sens. Certes le bon sens est un préalable mais il s’accompagne de rigueur, de méthode, d’autocritique, qualifiée de « retour d’expérience » en ingénierie système et surtout de relationnel. Par exemple, les apprenants se sont rarement confrontés à une vraie problématique du management de projet en équipe au niveau de la première année d’ingénieur. Ici le levier est la preuve : « Ca marche mieux avec que sans ! ».

22Enfin, au-delà de l’utilité, la motivation et l’engagement de l’apprenant dans un apprentissage sont fortement liés au contrat didactique. Il doit définir de manière claire et précise les rôles de chacun des intervenants : apprenants, enseignants.

2.2 Ingénierie pédagogique

23La bonne gestion d’une transposition didactique consiste, dans notre cas, à tenter d’optimiser trois critères essentiels :

  • une distance induite par la transposition didactique minimum ;

  • une reconstruction de préalables éventuels ;

  • un contrat didactique formalisé.

24Ils constituent les objectifs de l’ingénierie pédagogique du module. L’optimisation de ces critères doit permettre de trouver une bonne réponse pédagogique. Ces critères sont considérés comme essentiels vis-à-vis de l’enjeu de l’introduction de l’ingénierie système en première année. Il est à noter que le choix de ces critères n’est pas entièrement objectif. Il tient compte des expériences décrites par Meyne, (2004) et Descartes (1637/2000), du ressenti du public apprenant : niveau, motivation, capacité de travail entre autres.

25La définition précise de ces objectifs peut être identifiée avec l’ingénierie des exigences en ingénierie système. L’ingénierie des exigences consiste à définir des propriétés dont l’obtention est nécessaire à un système sous la forme d’une caractéristique, d’une aptitude ou d’une limite. Elle distingue deux types d’exigence : les exigences initiales et les exigences systèmes. Les exigences initiales concernent le besoin et les contraintes. La formalisation des contraintes est un outil conceptuel intéressant car elle permet de circonscrire la conception dans un cadre précis.

26L’intégration d’un nouveau module d’enseignement dans une structure déjà existante impose des contraintes de coût et de temporalité. La première année de l’ENSTA-ParisTech est ambitieuse sur le plan scientifique et technique. Il y a peu de place pour une nouvelle discipline. La seule solution trouvée a été de concentrer les enseignements d’ingénierie système sur une semaine et d’axer ceux-ci sur les aspects fondamentaux à savoir :

  • La problématique de la définition des exigences ;

  • La problématique de la conception ;

  • La problématique de la phase IVVQ : intégration, vérification, validation et qualification.

  • 2 La notion d’enseignement « utile » rend compte de la demande sociale visant à faire de l’enseigneme (...)

27Le parallèle entre la définition des objectifs et l’ingénierie des exigences peut, à mon sens, être étendu à l’ingénierie système tout entière. Il est possible d’identifier un acte pédagogique à un système. L’acte répond à un besoin et induit une transformation, comme le fait un système. La notion de système en ingénierie système ne se réduit pas au système physique. En ingénierie système, tout est système. Dans un article précédent (Meyne, 2004), j’avais déjà utilisé une méthode inspirée du management de projet pour de l’ingénierie pédagogique appliquée aux nouvelles technologies de l’enseignement. Interroger la notion de système dans une optique pédagogique est une généralisation de cette première démarche. Il me semble que l’enseignement « utile2 » exigé aujourd’hui par la société peut bénéficier des concepts de l’ingénierie système pour optimiser les coûts humains et financiers. Reste à savoir si l’enseignement « utile » est vraiment si utile que cela ?

28En résumé, l’ingénierie pédagogique doit conduire à une solution optimisant la distance, les conceptions préalables et le contrat didactique, en respectant les contraintes temporelles et de contenu.

2.2.1 Minimiser la distance

29« Nul savoir enseigné ne saurait s’autoriser de lui même » (Chevallard, 1994). Autrement dit, le savoir est légitime quand il s’appuie sur un besoin social clairement exprimé. Une grande part de la motivation provient de la capacité des apprenants à exprimer ce besoin. Or comment faire lorsque le besoin, comme dans le cas de l’ingénierie système, est éloigné des préoccupations des apprenants ? Une piste consiste à mettre les apprenants en situation à travers un jeu de rôle mettant en scène une relation « maîtrise d’ouvrage » et « maîtrise d’œuvre », soit un client et des équipes d’ingénieurs chargés de proposer un prototype.

30Cette situation existe dans plusieurs cadres. Un appel d’offres est un exemple classique de ce genre de relation. Parfois, ce type de situation se trouve même à l’intérieur d’une entreprise. Le cas de Samsung en est un exemple. L’étude d’un nouveau téléphone met en compétition des équipes d’ingénieurs de Samsung et le meilleur projet est retenu. Cette situation est facilement adaptable dans un cadre pédagogique, à condition de rester dans les limites de la déontologie. Entre autres, le sentiment de justice est un fondamental de l’adhésion des apprenants à un acte pédagogique.

31L’adaptation de cette situation s’appuie sur ce qui est désigné par « projet » dans l’enseignement. L’objet du projet doit faire émerger de manière évidente le concept de système en s’appuyant sur un dispositif d’étude qui intègre des aspects multi-physiques. À ce titre, la robotique est un candidat incontournable. Par nature, elle assemble des dispositifs issus du contrôle commande, du génie électrique courant fort et faible ainsi que des dispositifs mécaniques. Ce mélange est désigné sous le terme de mécatronique. Il induit naturellement le concept de système, à savoir un objet qu’il faut approcher sans a priori technologique et dont les constituants peuvent faire appel à plusieurs technologies. Ainsi, en première approximation, un robot peut être modélisé par trois sous-systèmes, un système permettant la prise en compte de l’environnement, un système de commande permettant la prise de décisions et un système permettant de mettre en œuvre les actions. Le tableau suivant résume les constituants principaux de ces systèmes :

Systèmes

Constituants

Prendre en compte l’environnement

Capteurs

Conditionneurs

Microcontrôleur

Dispositifs de communication

Prendre une décision

Dispositifs de communication

Microcontrôleurs

Gestion de l’énergie

Dispositif énergétique

Faire une action

Actionneurs

Contrôle commande

Dispositifs de communication

32Le tableau met en évidence la nécessité d’avoir une approche système. Une approche monophysique revient à privilégier un constituant par rapport aux autres et donc à obtenir une solution non optimale. Ainsi, une approche mécanique va tendre à optimiser les aspects actionneurs au détriment du reste de l’objet. L’approche système permet une vue globale et cherche à optimiser l’ensemble. Il existe d’autres systèmes éligibles pour ce type de projet : voiture, avion, bateau, etc. L’intérêt de la robotique, par rapport à ces systèmes, est la simplicité d’un robot, son aspect ludique et la facilité de mise en œuvre à travers du matériel ad hoc.

33Un bon moyen, aussi, de minimiser la distance entre le savoir « industriel » et l’apprentissage est de faire intervenir des ingénieurs directement en prise avec la problématique. Ces interventions, pour peu qu’elles ne soient pas construites comme des cours mais comme des témoignages, permettent de mettre en contact direct l’apprenant avec le professionnel. Si les concepts ont été présentés avant les témoignages, ceux-ci s’appuyant sur ces outils ancrent le savoir dans la réalité. Les intervenants peuvent servir aussi de conseil dans la démarche initiée par les apprenants.

2.2.2 Construction préalable

34Dans leur scolarité antérieure, les apprenants n’ont jamais été mis en présence d’une vraie problématique de conception, à savoir, se confronter à la recherche d’une solution nouvelle. L’ensemble des tâches assimilables à de la conception : étude des méthodes Strutured Analysis and Design Technique (SADT), projet de réalisation, travaux pratiques entre autres, n’avaient comme objectif que d’illustrer une discipline et donc de résoudre un problème résolu. L’enjeu était de trouver la solution à laquelle l’enseignant voulait les conduire. Or pour arriver à cette solution, étaient suggérés, parfois fortement, une méthode et des outils par l’enseignant. Ces méthodes, parfois inspirées de l’industrie mais déformées par l’objectif particulier, impliquent des constructions préalables. Ces derniers conduisent les apprenants s’ils ont une origine « mécanique » à penser comme des mécaniciens, s’ils ont une origine « électronique » à penser comme des électroniciens, etc. et donc à envisager l’objet sous l’angle de ses constituants technologiques et non sous l’angle de son architecture. Or l’objet même de l’ingénierie système est de se dégager de la technologie, considérée comme un moyen et non comme une fin.

35Pour éviter que les constructions préalables ne conduisent à une solution typée technologiquement, il faut placer les apprenants dans une situation où la technologie n’a pas d’importance. Ainsi le matériel nécessaire à la réalisation du robot sera imposé sous la forme d’une exigence initiale. Ainsi dégagés des contingences technologiques, les apprenants se concentreront sur la méthode et l’architecture du robot et devront de fait considérer les objets comme des systèmes.

36Il ne faut pas non plus que les apprenants confondent projet robotique et projet d’ingénierie système. Dans ce cas, l’apprentissage n’interrogerait pas la méthode. L’important, pour ce module, est moins de faire fonctionner le robot que de comprendre pourquoi il fonctionne ou non. Les apprenants doivent être capables d’analyser leur démarche afin de déterminer où réside l’erreur qui conduit au non-fonctionnement du robot. À l’inverse, si le robot a fonctionné, les apprenants doivent être capables de formaliser ce qui caractérise la bonne pratique qui conduit à la réponse aux exigences initiales et systèmes. Les méthodes d’ingénierie système leur donnent des outils conceptuels pour ce type d’analyse. Ces outils sont souvent désignés par le terme : RETEX (retour d’expérience).

2.2.3 Contrat didactique

37La mise en situation proposée ne s’inscrit pas dans le contrat didactique implicite classique qui s’apparente à l’approche anthropologique décrite par Sarrazy (1995). Il n’y a pas dans cette situation, une relation maître-apprenants à laquelle les apprenants sont habitués. Dans une situation de type jeu de rôle, les apprenants vont devoir mobiliser leur savoir et savoir-faire, voire leur savoir-être, au fur et à mesure que les écueils vont se présenter. Il apparaît indispensable de formaliser avec précision le nouveau contrat didactique qui leur sera proposé. Celui-ci doit définir les règles de fonctionnement et de relations, comme dans tout jeu de rôle, en s’inspirant de cas réels.

38Dans une relation commerciale de type appel d’offres, le client, qui se trouve dans une posture de maîtrise d’ouvrage, n’a pas la solution au problème qu’il pose. En revanche, il doit pouvoir circonscrire celle-ci dans un cadre défini par les exigences initiales techniques et temporelles, les processus de validation et de qualification. La maîtrise d’ouvrage n’a pas à régir l’organisation interne de la maîtrise d’œuvre. Cette organisation est du domaine seul de la maîtrise d’œuvre. La maîtrise d’ouvrage ne définit que les règles de communication entre elle et la maîtrise d’œuvre.

39La transposition de cette situation en jeu de rôle est assez simple. Elle doit être écrite de façon à disposer d’un document de référence et expliquée en détail lors d’une présentation.

3. Le dispositif

40Le dispositif pédagogique repose donc sur les objectifs suivants :

  • mise en situation à travers un jeu de rôle, associé à des témoignages d’ingénieurs ;

  • un contrat didactique définissant les règles du jeu, tant sur le plan relationnel que sur le plan de la validation du projet.

3.1 Description

41Le dispositif est construit sur une semaine. Ce rythme hebdomadaire est imposé par l’emploi du temps. Il commence par une introduction à l’ingénierie système qui donne les clés minimales de cette discipline et les objectifs de la semaine. La présentation, sur une matinée, permet de préciser le contrat didactique.

42Le reste du temps est partagé entre la mise en situation sous la forme d’un projet en équipe et des conférences où des ingénieurs viennent témoigner de leur expérience en tant qu’« ingénieur système ».

43La conception des témoignages des professionnels a été accompagnée de façon à ce qu’ils ne deviennent pas des cours sur l’ingénierie système. L’important était de montrer aux apprenants que l’ingénierie système est une discipline qui correspond à des métiers relativement bien identifiés et identifiables dans les grands groupes industriels. Ils devaient comporter deux parties. La première partie était centrée sur : « Comment, en tant qu’ingénieur système, je considère, ou je caractérise l’ingénierie système dans ma pratique quotidienne et comme outil institutionnel ? ». La seconde partie était centrée sur un projet qui utilisait l’ingénierie système et auquel l’intervenant avait participé. Ainsi les conférences suivantes ont été proposées : « ATV et ingénierie système » par G. Auvray, d’Astrium, « Laser Méga Joule » par A. Reichart, directeur adjoint de l’ENSTA-ParisTech, et « IS et recherche » par O. Hammami, enseignant-chercheur à l’ENSTA-ParisTech.

44Le projet a été structuré en deux temps : un temps de conception et un temps de réalisation. Ces deux temps suivent les deux branches du « cycle en V », classique dans ce type de méthode. Le premier temps concerne l’ingénierie des exigences, les spécifications et la conception de l’architecture du système.

Fig. 1 : cycle en V — déroulement du projet.

Fig. 1 : cycle en V — déroulement du projet.

45Il se conclut par la remise d’un dossier de conception, qui contient les exigences du système, l’architecture et la description de la phase IVVQ (intégration, vérification, validation et qualification).

46À la suite de la remise du dossier les apprenants ont reçu le matériel pour la réalisation du robot. Ils ont réalisé le robot, l’ont testé et « l’ont qualifié » lors d’une pseudo-compétition. Il s’agissait de combats de sumo opposant deux robots dans un dohyõ. Le dohyõ était un plateau circulaire de 70 cm de diamètre, délimité par une bande réfléchissante.

Fig. 2 : forme du dohyõ.

Fig. 2 : forme du dohyõ.

47Le combat se déroule de la manière suivante :

48Un opérateur pose le robot sur l’emplacement A ou B. Au signal, les étudiants mettent en marche les robots. Les robots doivent rester inactifs pendant trois secondes puis se mettre en fonctionnement.

49Le robot doit expulser le robot adverse hors du dohyõ. Un robot est considéré comme expulsé s’il est en totalité hors du terrain.

50Un combat dure deux minutes. Si, au bout de ce temps, aucun robot n’est hors du terrain, alors le combat est déclaré nul.

51Il s’agissait d’une pseudo-compétition, dans la mesure où elle s’est résumée à des simples combats sans organisation type tableau, poule, quart, demi, grande et petite finale. En effet, le projet n’est pas un projet de robotique mais un projet d’ingénierie système. L’objet des combats était de qualifier le robot, à savoir, de placer le robot dans les conditions de fonctionnement demandées lors de l’ingénierie des exigences, non de remporter une victoire.

52À l’issue de ce second temps, les équipes devaient remettre un compte rendu décrivant la partie IVVQ et les différentes adaptations qu’elles avaient dû réaliser par rapport à la phase de conception.

3.2 Étude de marché robotique

53Le choix du matériel nécessaire à la construction des robots s’est effectué à la suite d’une étude de marché rapide dont le résultat est résumé dans le tableau suivant :

54Le matériel proposé par la société GEARS-ID est constitué d’une mallette de type « Mécano », c’est-à-dire des éléments mécaniques en modèle réduit avec, en plus, un kit dit « électronique », lui-même constitué d’un système programmable et d’un système de commande. En fait, il s’agit du matériel idéal pour ce type de projet, dans la mesure où il permet de concevoir un robot complet, des constituants mécaniques à l’électronique. Néanmoins, le prix est trop élevé pour le nombre d’équipes engagées dans le projet (19 équipes). La solution « Mécano » recelait un potentiel intéressant. Cependant, Mécano ne propose pas de système de programmation et de commande. Il aurait donc fallu le faire réaliser par les étudiants, ce qui n’était pas possible dans le temps imparti. Une autre solution est l’utilisation des produits « Lego Technic ». Ce qui joue en défaveur de Lego Technic, pourtant souvent utilisé pour ce type de projet, est l’aspect jouet du robot obtenu avec des éléments Lego. Les éléments Lego ont une forme rectangulaire. Ils s’emboîtent les uns sur les autres, ce qui interdit toute vision « structure » du robot comme par exemple le dimensionnement de ses éléments constitutifs.

55Il reste donc les kits « Bioloid beginner ». Il s’agit d’un ensemble de pièces mécaniques, d’actionneurs et de capteurs qui peuvent être assemblés entre eux par un système d’écrous et de boulons. Les actionneurs et les capteurs sont commandés par un boîtier de commande construit autour d’un processeur ATMEL Atmega 128. Il s’agit d’un processeur de la famille AVR construit autour d’une architecture RISC (Tavernier, 2009). La configuration des pièces permet de construire plus d’une vingtaine de configurations différentes. Enfin, la communication boîtier de commande actionneur s’effectue via un réseau local propriétaire dont la mise en œuvre est très simple.

56Pour la programmation, les étudiants peuvent utiliser les outils de programmation proposés par Bioloid avec le matériel. Il s’agit d’outils graphiques sous Windows très simples à mettre en œuvre.

57Un autre choix consiste à programmer directement le processeur ATMEL en C, soit avec des outils standard du type gcc soit sous Windows ou sous Linux. Sous Linux, la difficulté réside dans la maîtrise de l’outil de programmation In Situ du processeur ATMEL. En effet, selon les configurations, celui que l’on trouve (UISP) ne fonctionne pas toujours. Sous Windows, l’outil de programmation In Situ fourni par Bioloid fonctionne sans souci. Sous les deux systèmes d’exploitation, il existe des bibliothèques C permettant de ne pas aborder la couche matérielle, en particulier au niveau de la gestion du réseau local. Néanmoins la simplicité des protocoles fait que la prise en main du système est très simple.

3.3 Résultats

58Il y avait 19 équipes en lice pour ce projet. Le déroulement de la semaine est résumé dans le tableau suivant :

59Toutes les équipes ont joué le jeu. Je jouais le rôle du client et j’ai, au cours de la semaine, modifié une partie des données du problème. Il s’agissait, en effet, de montrer qu’une démarche d’ingénierie système bien conduite permet de gérer des ruptures en minimisant les conséquences. Ainsi au départ, il était fortement conseillé d’utiliser une programmation en langage C. Or pour des raisons diverses, il s’est avéré que les outils de programmation C ne fonctionnaient pas et qu’il fallait utiliser d’autres outils de programmation comme ceux de Bioloid. Une conception orientée sur le C, c’est-à-dire une absence de modélisation de l’architecture et/ou une programmation directe rend cette rupture quasiment impossible dans le temps imparti. En revanche, la description d’une architecture constituée de systèmes dont le fonctionnement est correctement décrit en terme de modification de flux entrant vers des flux sortants permet de s’adapter rapidement à une modification d’outil.

60Un autre point, mis en exergue par la modification de ce type d’exigences au cours de la semaine, est la nécessité de penser, en même temps que la conception de l’architecture en elle-même, celle des produits contributeurs. Un produit contributeur est un système qui contribue à la conception, à la mise en œuvre et le maintien en service ainsi qu’au retrait de service d’un système. En fait, le cycle en V n’est qu’une vision partielle de la conception, un cycle plus proche de la réalité est le cycle en W.

Fig. 3 : cycle en W.

Fig. 3 : cycle en W.

61Ce cycle fait apparaître le V du système et le V d’un ou des produits contributeurs. En fonction des systèmes, la mise en service de ces produits contributeurs doit intervenir avant la réalisation, comme dans le cas d’un outil de développement, ou après, dans le cas d’un outil de retrait de service. Cette vision de la conception permet de traduire les exigences en données d’entrée pour les méthodes de management de projets, particulièrement pour les diagrammes qui illustrent l’utilisation des ressources humaines et techniques.

62Si les apprenants ont bien géré les aspects de modélisation, l’aspect W n’a pas été mis vraiment en évidence dans leurs travaux.

63Tous les robots ont fonctionné in fine dans le temps qui avait été imposé. Imposer une phase de conception papier avant la réalisation et placer les apprenants dans une situation de compétition ont conduit à peu, voire à aucune diffusion de solution. Ainsi, les 19 équipes ont construit 19 robots à peu près différents, comme il est possible de le visualiser sur la figure 4.

Fig. 4 : les 19 robots de la compétition.

Fig. 4 : les 19 robots de la compétition.

64Cette comparaison est intéressante. Il est, en effet, possible de conjecturer que l’ingénierie système comme méthode de conception bride la créativité et l’innovation. Pourtant, partant du même cahier des charges, des mêmes exigences, les 19 équipes ont abouti à des solutions différentes. Il est possible de classer ces robots par familles : ceux du type buffle, ceux du type pelle, avec ou sans protection sur le côté.

3.4 Évaluation

65Une évaluation a été demandée aux étudiants sous la forme d’un questionnaire anonyme. L’idée du questionnaire, outre les aspects liés à la qualité, consistait à évaluer l’adhésion des apprenants au projet « ingénierie système » de l’école. Ce projet étant de proposer une initiation à travers une pédagogie par projet de l’ingénierie système.

66De ce point de vue, cette semaine est une réussite. Aux questions suivantes :

  • Pensez-vous que l’ingénierie système est une discipline importante pour l’industrie aujourd’hui ?

  • Estimez-vous nécessaire d’avoir un enseignement d’ingénierie système dans votre cursus ?

  • Estimez-vous que l’enseignement de l’ingénierie système passe obligatoirement par la mise en œuvre d’un projet ?

67Les apprenants répondent par oui respectivement à 89 %, 84 % et 95 %. Les apprenants adhérent donc pratiquement sans réserve à l’ingénierie système. En revanche à la question : « Comment qualifieriez-vous l’organisation de la semaine de l’ingénierie système ? », ils répondent à 58 % très mauvaise et mauvaise, en pointant du doigt, principalement, l’absence de préparation au niveau des outils. On peut lire dans l’espace « libre expression » du questionnaire : « scandaleux », « odieux », « vide et absence de réponses » ou » une semaine dédiée à l’ingénierie système qui organise les plus grands projets techniques du monde sans organisation … cherchez l’erreur ! ». Ces réponses montrent l’ambiguïté de l’approche : d’accord pour l’ingénierie système, mais à condition de ne pas avoir à assumer la totalité de l’implication de l’ingénierie système. Cette ambiguïté est le résultat d’une approche systématiquement passive. Alors même que les étudiants en école d’ingénieurs sont capables de se prendre en main pour organiser un gala, animer des associations, s’impliquer dans le sport et autres activités, ils ne transposent pas cet engagement dans l’enseignement.

68Ce point négatif résulte, à mon sens, d’une erreur d’appréciation. Du point de vue enseignement, le fonctionnement du robot, bref le résultat, c’est-à-dire, entre autres, le fonctionnement des robots, la gestion des ruptures, justifie a posteriori la réussite de la démarche. Or il semble que ce ne soit pas vrai pour les étudiants. Nous aurions dû expliquer aux étudiants l’excellence de leur résultat. Ce constat est aussi une conséquence d’une approche systématiquement passive où l’échec est plus pris en compte que la réussite.

Conclusion

69Globalement, les objectifs de cette semaine de l’ingénierie système ont été atteints. Les points négatifs, mis en évidence lors de l’évaluation, seront évités en mettant en place deux actions :

  • meilleure communication des objectifs en amont et aval auprès des étudiants ;

  • accroissement du caractère « jeu d’entreprise » de cette semaine en formalisant mieux les rôles : client, appel d’offres. Ce type de jeu existe dans le domaine tertiaire. Il s’agit de s’en inspirer, en mettant en scène un appel d’offres.

70L’important était de montrer suffisamment tôt dans un cursus l’importance croissante de l‘ingénierie système et d’en donner les premières clefs. En troisième année, les étudiants pourront en effet choisir une filière ingénierie système composée d’un module de 84 heures spécifique à l’ingénierie système, et des modules métiers, en fonction du domaine industriel dans lequel ils souhaitent exercer.

71L’adhésion des étudiants au projet ingénierie système et l’intérêt qu’ils ont montré lors de la semaine : investissement, respect des contraintes temporelles, montrent qu’à quelques améliorations près, cette semaine de l’ingénierie système a été un succès.

Haut de page

Bibliographie

AFIS (2009). Découvrir et comprendre l’ingénierie système. Association française d’ingéniérie système/Groupe de travail ingénierie système, [version 3].

CHEVALLARD Y. (1991). Concepts fondamentaux de la didactique : perspectives apportées par une approche anthropologique. Recherches en didactique des mathématiques, vol. 12, n° 1, p. 73-112.

CHEVALLARD Y. (1994). Processus de transposition didactique et leur théorisation. In G. Arsac, Y. Chevallard, J-L. Martinand & A. Tiberghien (dir.), La transposition didactique à l’épreuve, Grenoble : La pensée sauvage, p. 135-180.

DESCARTES R. (1637/2000). Le Discours de la méthode pour bien conduire sa raison et chercher la vérité dans les sciences. Paris : Le livre de poche.

MEYNE P. (2004). Ingénierie pédagogique et NTE comment faire ? Actes du colloque TICE 2004.

SARRAZY B. (1995). Le contrat didactique. Revue française de pédagogie, n° 112, p. 85-118.

TAVERNIER C. (2009). Miconcontrôleur AVR : des ATtiny aux ATmega. Paris : Dunod, (2e éd.).

VERRET M. (1975). Le temps des études. Paris : H. Champion, 2 vol. 

Sites Web

Site de l’INCOSE : <www.incose.org>.

Site de l’AFIS : <www.afis.fr>.

Page système : <www.ensta.fr/~meyne>.

Haut de page

Notes

1 La DGA est notre instance de tutelle. Cependant, elle intervient ici comme opérateur industriel.

2 La notion d’enseignement « utile » rend compte de la demande sociale visant à faire de l’enseignement un moyen de s’insérer dans la société principalement en permettant un accès facile à l’emploi.

Haut de page

Table des illustrations

Titre Fig. 1 : cycle en V — déroulement du projet.
URL http://journals.openedition.org/rdst/docannexe/image/536/img-1.png
Fichier image/png, 204k
Titre Fig. 2 : forme du dohyõ.
URL http://journals.openedition.org/rdst/docannexe/image/536/img-2.png
Fichier image/png, 292k
URL http://journals.openedition.org/rdst/docannexe/image/536/img-3.png
Fichier image/png, 236k
URL http://journals.openedition.org/rdst/docannexe/image/536/img-4.png
Fichier image/png, 5,9k
Titre Fig. 3 : cycle en W.
URL http://journals.openedition.org/rdst/docannexe/image/536/img-5.png
Fichier image/png, 191k
Titre Fig. 4 : les 19 robots de la compétition.
URL http://journals.openedition.org/rdst/docannexe/image/536/img-6.png
Fichier image/png, 717k
Haut de page

Pour citer cet article

Référence papier

Philippe Meyne, « Retour d’expérience sur l’enseignement de l’ingénierie système »RDST, 4 | 2011, 197-214.

Référence électronique

Philippe Meyne, « Retour d’expérience sur l’enseignement de l’ingénierie système »RDST [En ligne], 4 | 2011, mis en ligne le 15 février 2014, consulté le 29 novembre 2021. URL : http://journals.openedition.org/rdst/536 ; DOI : https://doi.org/10.4000/rdst.536

Haut de page

Auteur

Philippe Meyne

philippe.meyne@ensta-paristech.fr
École nationale supérieure de techniques avancées ENSTA ParisTech

Haut de page

Droits d’auteur

© Éditions de l’École normale supérieure de Lyon

Haut de page
  • Logo Université de Lyon
  • Logo ENS Éditions
  • Logo Institut français de l’éducation
  • OpenEdition Journals
Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search