Origines des travaux

Afin de mieux appréhender la nature mais également la structure de ces travaux, il est

opportun d’en rappeler les origines. La Figure 1.21 rappelle ces origines et l’influence

que ces dernières ont eue sur les objectifs et sur la problématique.

Figure 1.21 Les origines des travaux

Sur la partie gauche de la figure, les expériences professionnelles sont rappelées. La

première expérience notable concerne le développement logiciel. Durant cinq années, j’ai

en effet eu l’occasion de travailler en tant qu’ingénieur développeur au sein de la société

Dassault Systèmes, tout d’abord au service recherche puis sur les solutions

Knowledgeware (solutions de Knowledge Based Engineering – KBE) intégrées à

l’ensemble du portefeuille de produits. Durant les trois dernières années, j’ai également

été en charge du suivi des indicateurs qualités pour l’ensemble du département

développant ces solutions. Ce suivi consiste en la collecte journalière d’informations

concernant les interventions considérées comme prioritaires à la fois au sein du système

d’information, mais également auprès des développeurs en charge de ces interventions.

Ces informations sont ensuite partagées lors d’une courte réunion auprès du responsable

de la marque, afin de préparer la réunion exécutive journalière, réunissant notamment

l’ensemble des responsables des différentes marques. Lors de cette réunion exécutive, des

arbitrages sont effectués et de nouvelles priorités sont définies. Ces dernières sont

Objectif: intégration multidisciplinaire

inspirée des méthodes agiles

(hardware/software notamment)

Bibliographie

Conception collaborative multidisciplinaire Mécatronique

Expériences professionnelles

Dassault Systèmes => Méthodologie de développement logiciel (software) UTC => Méthodologies de conception produit (hardware) Améliorer la collaboration Assurer la traçabilité décisions/ données Faciliter la prise de décisions

Problématique

Systèmes conçus faiblement intégrés car: - Faible collaboration entre les disciplines - Cloisonnement trop important

renseignées dans le système d’information, afin de permettre la propagation de ces

décisions. Ce mode de pilotage basé sur des informations quotidiennes en provenance du

terrain et les outils supports à ce pilotage sont en partie à l’origine de l’objectif et des sous

objectifs décrits précédemment. Plus globalement, cette expérience professionnelle m’a

permis d’acquérir une vision précise quant à une méthodologie de développement

logicielle appuyée sur la mise en œuvre de méthodes agiles.

La seconde expérience professionnelle notable, toujours en cours, concerne les

méthodologies de conception de produit. Depuis six ans maintenant, je travaille en tant

qu’enseignant chercheur au département Génie des Systèmes Mécaniques à l’Université

de Technologie de Compiègne. Mes enseignements ont notamment trait aux méthodes de

conception collaboratives de systèmes mécaniques. Mes activités de recherche sont

menées au sein du laboratoire Roberval, dans le groupe « ingénierie industrielle » qui vise

à intégrer les expertises et disciplines impliquées lors de la conception-industrialisation de

produit. Ce groupe de recherche travaille étroitement avec le groupe «

micro-mécatronique » au sein d’un axe en émergence intitulé « Systèmes Intégrés en

Mécanique ». Le travail au sein de ces équipes, ainsi que les différents contacts industriels

inhérents à ces activités, ont fortement contribué à obtenir une vision globale sur les

méthodologies de conception de produit et sur les outils utilisés durant cette conception.

Ces contacts industriels m’ont notamment permis de découvrir les problématiques

induites par la conception de systèmes mécatroniques. Bien plus que l’évolution

séquentielle d’un produit mécanique intégrant progressivement des capteurs, des

actionneurs, de l’électronique et du logiciel embarqué, la conception de systèmes

mécatroniques fait appel à une très grande diversité d’expertises, issues de différentes

disciplines. Par exemple, des équipementiers automobiles concevant et fabricant des

systèmes comme les systèmes de climatisation, les systèmes d’assistance à la conduite

etc. ont ainsi été confrontés à une véritable mutation de leur métier d’origine. En quelques

années, ils sont passés de concepteur/fabricant mécanique à intégrateur de solutions

basées sur des expertises électriques, électroniques et logicielles. Les outils de travail

collaboratif du marché qu’ils achevaient à peine de déployer, ou tout du moins de

projet de conception. Encore maintenant, les initiatives les plus avancées pour ces

différents acteurs ont trait à l’intégration des expertises électriques et électroniques au

sein des solutions PDM mécaniques. La prise en considération de la partie logicielle du

système au sein d’une même plateforme n’est donc encore qu’une lointaine perspective.

Certains d’entre eux commencent à échanger autour de l’ALM, mais les solutions mises

en place servent à organiser exclusivement le développement de la partie logicielle, et ce,

de façon complètement cloisonnée.

Ces contacts industriels m’ont également amené à constater la complexité croissante des

organisations et la lourdeur de certains mécanismes mis en œuvre dans les PDM actuels.

Pour faire face à la complexité croissante liée aux activités de conception des produits,

des processus de plus en plus précis et complexes sont élaborés et formalisés au sein de

solutions telles que les PDM. Ces processus permettent en effet de faire collaborer un

nombre d’acteurs toujours croissant, mais il nous semble également induire une

croissance du temps global consacré aux tâches administratives. De la même manière, les

nouvelles fonctionnalités offertes par les logiciels de gestion de données et de

collaboration viennent en permanence s’ajouter aux précédentes sous la forme de

nouveaux modules, complexifiant l’usage et l’ergonomie de ces solutions. Au final, les

utilisateurs ont l’impression de ne plus avoir des outils leur permettant de travailler, mais

plutôt de travailler pour les outils; ils n’ont plus l’impression d’être au cœur du processus

de conception. Ce ressenti est essentiellement basé sur des échanges réalisés avec des

concepteurs et des administrateurs de systèmes de gestion de données et de collaboration

issus de différents domaines industriels, notamment du transport. À l’inverse, les

processus et les outils utilisés dans le cadre du développement informatique nous

apparaissent comme beaucoup plus « simples » et flexibles. Cette simplicité est toute

relative car de nombreux mécanismes également complexes sont mis en œuvre, mais ils

n’apparaissent pas dans le contexte d’usage. Les interfaces et les fonctions proposées sont

épurées. De même, une grande indépendance est laissée aux développeurs qui disposent

d’une feuille de route générale et s’organisent ensuite avec une grande liberté pour

atteindre les objectifs qui leur sont fixés. Cette forme d’agilité, qui est évoquée tout au

long de ce manuscrit, fait également parti des constats ayant contribué à mes travaux.

Sur la base de ces deux expériences professionnelles est né l’objectif de venir proposer

une méthodologie de conception de système unifiant les pratiques issues des domaines

hardware et software, qui serait matérialisée par une plateforme de collaboration et de

gestion de données commune, dynamique et adaptée aux différents acteurs issus des

différentes disciplines. L’idée sous-jacente est ainsi de « prendre le meilleur » de chacune

des pratiques et de les adapter pour les rendre compatibles avec les exigences de

l’ensemble des disciplines impliquées.

Si les objectifs et sous objectifs ont été principalement déterminés grâce aux constatations

industrielles, la problématique a, quant à elle, été formalisée grâce à une étude

bibliographique portant sur les méthodologies de conception collaborative visant à faire

coopérer des experts métiers issus de différentes disciplines. Cette bibliographie a été

complétée par des recherches concernant la mécatronique, considérée dans ces travaux

comme un cadre applicatif de prédilection.

La bibliographie menée a été relativement longue et large car elle vise à la fois à

connaître les méthodes employées dans le cadre de la conception de produits et de

systèmes, les méthodes utiles à la collaboration, les travaux menés visant à l’intégration

produit, les contributions liées à l’intégration multidisciplinaire etc. Cette étude s’est dans

un premier temps focalisée sur les travaux de la communauté dont je suis issu, à savoir la

communauté liée à l’ingénierie collaborative et à la conduite du cycle de vie produit.

Mais elle s’est rapidement concentrée sur l’intégration multidisciplinaire, en se basant

notamment sur les problématiques induites par la conception de systèmes mécatroniques.

Les contributions de type méthodologique pour la conception de ce type de systèmes sont

généralement très liées à l’ingénierie système, où j’ai donc dû effectuer quelques

recherches. La plupart des travaux développés dans ces diverses communautés se

focalisent sur l’intégration via les modèles de données dans les phases amont de la

conception. La dynamique des échanges et les aspects organisationnels n’y sont que très

peu traités, notamment durant les phases de conception détaillées.

Le fait de ne pas identifier de contribution visant à rendre le processus de conception plus

agile et flexible m’a amené à chercher du côté des méthodes dédiées au développement

logiciel. L’ALM et les méthodes agiles sont dès lors devenus des sources de

connaissances pour proposer une méthode agile pour la conception collaborative

multidisciplinaire.

La partie droite de la Figure 1.21 rappelle les deux familles de travaux ayant conduit à

l’élaboration de notre problématique portant sur l’intégration multidisciplinaire présentée

ci-avant.

En s’appuyant sur ces sous-objectifs et sur la problématique, l’hypothèse a ainsi pu être

déterminée. Elle est présentée dans la section suivante.

Dans le document Méthode agile pour la conception collaborative multidisciplinaire de systèmes intégrés : application à la mécatronique (Page 77-81)