.

Licence Pro. RESEAU GENIE

LOGICIEL 2e ANNEE
Support de cours

Conception système
https://m.youtube.com/watch?v=lqckNSBc-
oo&t=6s&pp=2AEGkAIB0gcJCdgAo7VqN5tD

Information II

01 BP 2585 ABIDJAN République de Côte d’lvoire

www.pigierci.com

[email protected] DR. Christophe Merlo

Rapport d’habilitation Christophe MERLO

Introduction

Ce document synthétise près de vingt ans d’une carrière originale pour un enseignant-
chercheur, dans la mesure où cette vocation n’est venue que progressivement.

Titulaire au départ d’un D.E.S.S. en Mathématiques Appliquées à l’Informatique, j’étais

destiné à développer des outils d’analyse numérique au sein d’entreprises de
développement informatique. Fort heureusement les hasards de la vie ont voulu que
j’atterrisse à ce qui est devenue aujourd’hui l’ESTIA dès ma ‘mise sur le marché’. Ce fut mon
premier contact avec l’enseignement d’une part, et avec la CAO et la conception de produits
d’autre part.
Pendant une dizaine d’année j’ai donc exercé un double métier, celui d’enseignant et
celui de consultant en entreprise. Ce furent des années exigeantes sur le plan professionnel
mais extrêmement enrichissantes : accompagner des PME et des grandes entreprises dans
des projets technologiques permet d’apprendre beaucoup et très vite. Cette expérience est
également une façon d’aborder les questions de pédagogie avec un point de vue très
pratique, et d’apporter aux étudiants des exemples industriels et des problématiques
concrètes.
Quand l’opportunité de passer un D.E.A. puis une thèse me fut offerte, je l’ai aussitôt
saisie dans la mesure où l’action directe en entreprise ne m’apportait plus autant de
satisfaction. Le besoin de prendre du recul par rapport aux problèmes à court terme, l’envie
de réfléchir à des solutions plus globales et à plus long terme, m’ont poussé dans cette
démarche qui m’a fait changé progressivement de métier. J’ai donc basculé non sans
difficultés d’un état d’esprit de consultant – enseignant à celui d’enseignant-chercheur.

Mes travaux de recherche sont restés centrés sur les thématiques que j’avais
développées : la conception de produits, en particulier les outils supports pour la conception
(métiers et PLM) et surtout la conduite de la conception. J’ai ainsi pu bénéficier de mes
expériences industrielles de consultant pour traiter les problématiques de recherche avec la
préoccupation constante de rendre mes contributions applicables. Tout au long de la
description de mes travaux de recherche on retrouvera des projets de recherche, ou des
développements d’outils informatiques, ou des méthodes de mise en œuvre, qui
correspondent à cette préoccupation.
Cette double carrière, finalement, explique pourquoi je suis capable de démontrer une
longue expérience en enseignement, un grand nombre de projets menés avec des
industriels, ainsi qu’une mise en cohérence de mes axes de recherche, malgré un délai de
six années entre ma soutenance de thèse en 2003 et cette habilitation en 2009.

Le présent document se décompose en deux grandes parties précédées d’une

description rapide de mon parcours sous la forme d’un CV.

La première partie (chapitre 2) est un Curriculum Vitae étendu. Il présente sous forme de
tableaux synthétiques puis de façon détaillée les principaux critères quantitatifs et qualitatifs

5
Rapport d’habilitation Christophe MERLO

de mes activités d’enseignement, de recherche puis de projets de valorisation ou de

transfert.
La seconde partie (chapitre 3) développe dans le détail l’ensemble des activités de
recherche. Les résultats scientifiques présentent de façon structurée l’ensemble de mes
contributions centrées sur l’étude d’environnements d’assistance pour la conduite de la
conception collaborative. J’y présente la démarche de recherche qui est à la base de mes
travaux et je développe ces résultats suivant trois axes complémentaires : un axe dédié à la
conduite de la conception, un axe dédié à l’étude de la collaboration entre acteurs, et enfin
un axe fédérateur dédié aux environnements d’assistance. Est exposée ensuite la cohérence
d’ensemble de mes travaux scientifiques et leur synergie avec les principaux projets, outils et
enseignements réalisés, avant de définir les orientations thématiques prévues des
recherches qui sont engagées aujourd’hui et pour les prochaines années.
Il se termine par la liste complète de mes publications.
Cette partie est complétée par la bibliographie évoquée lors de la description de mes
résultats de recherche.

6
Rapport d’habilitation Christophe MERLO

SOMMAIRE

1. CURRICULUM VITAE ........................................................................................................................... 13

1.1. ETAT CIVIL .............................................................................................................13
1.2. TITRES ET DIPLOMES ..............................................................................................14
1.3. FONCTIONS OCCUPEES DANS LE CADRE DE L’ENSEIGNEMENT ET DE LA RECHERCHE ..15
1.4. AXES DE RECHERCHE ET ACTIVITES DE COORDINATION ............................................16
2. BILAN DETAILLE DE MES ACTIVITES............................................................................................ 17
2.1. ACTIVITES D’ENSEIGNEMENT ...................................................................................17
2.1.1. Bilan quantitatif des activités d’enseignement .............................................................................. 17
2.1.2. Domaines d’enseignement personnels et filières........................................................................... 18
2.1.3. Principales responsabilités pédagogiques et administratives ....................................................... 21
2.1.4. Autres missions et activités d’animation pédagogiques ................................................................ 23
2.2. ACTIVITES DE RECHERCHE ......................................................................................33
2.2.1. Bilan quantitatif des actions de recherche .................................................................................... 33
2.2.2. Encadrements scientifiques ........................................................................................................... 37
2.2.3. Animation scientifique................................................................................................................... 43
2.2.4. Les activités internationales.......................................................................................................... 50
2.2.5. Production d’outils logiciels ......................................................................................................... 53
2.3. ACTIVITES DE VALORISATION ET DE TRANSFERT SCIENTIFIQUE ..................................55
2.3.1. Bilan quantitatif pour la valorisation et le transfert ..................................................................... 55
2.3.2. Les projets à vocation scientifique ................................................................................................ 56
2.3.3. Les collaborations industrielles de transfert de technologie......................................................... 61
2.3.3.1. Collaborations depuis 2000 (ESTIA Recherche)................................................................................. 61
2.3.3.2. Collaborations antérieures à 2000 (ESTIA Innovation)....................................................................... 63
3. SYSTEMES D’INFORMATION SUPPORTS AUX ACTEURS DE LA CONCEPTION................. 65
3.1. CONTEXTE ET PROBLEMATIQUE ...............................................................................67
3.1.1. De la conduite des systèmes à la thématique de recherche........................................................... 67
3.1.2. La méthodologie de recherche suivie ............................................................................................ 69
3.1.3. Les principales contributions ........................................................................................................ 71
3.2. AXE SYSTEME : LA METHODOLOGIE GRAI INGENIERIE POUR LA CONDUITE DE LA
CONCEPTION ......................................................................................................................77
3.2.1. Contexte initial : Représentation du système de conception ......................................................... 78
3.2.2. Contribution : Méthode GRAI Ingénierie...................................................................................... 80
3.2.3. Contribution : Modélisation des connaissances pour la conduite ................................................ 83
3.2.4. Contribution collective : Mise en œuvre de la conduite................................................................ 86
3.3. AXE ACTEURS : L’ETUDE DES COLLABORATIONS ENTRE ACTEURS ............................91
3.3.1. Contribution : Méthode d’analyse des mécanismes collaboratifs................................................. 92
3.3.2. Contribution : Un modèle pour l’analyse de la collaboration ...................................................... 94
3.3.3. Contribution : Un outil support, CoCa ......................................................................................... 97
3.3.4. Synthèse : Coordination et collaboration, 2 concepts liés .......................................................... 101
3.4. AXE ENVIRONNEMENTS D’ASSISTANCE : LA PROPOSITION DE SYSTEMES
D’INFORMATION POUR LA CONDUITE ET LES ACTEURS ........................................................103
3.4.1. Contribution : Méthode pour la spécification conceptuelle d’environnements d’assistance...... 104
3.4.2. Contributions : Des environnements d’assistance pour la conduite ........................................... 108
3.4.3. Contributions : Des environnements d’assistance pour le PLM ................................................. 116
3.4.4. Contribution collective : Déploiement de solutions logicielles en entreprise ............................. 125
3.5. SYNTHESE ET PERSPECTIVES ................................................................................133
3.5.1. L’affirmation d’un schéma de recherche .................................................................................... 133
3.5.2. Perspectives : vers des environnements d’assistance interopérables ......................................... 134
4. DETAILS DES PUBLICATIONS.......................................................................................................... 139
5. BIBLIOGRAPHIE .................................................................................................................................. 149
6. ANNEXES ................................................................................................................................................ 155

7
Rapport d’habilitation Christophe MERLO

8
Rapport d’habilitation Christophe MERLO

Liste des figures

Figure 1. Evolution des publications dans des revues internationales ................................................................. 34
Figure 2. Evolution des publications dans des conférences internationales......................................................... 35
Figure 3. Liens entre stratégie et action ............................................................................................................... 68
Figure 4. Mes trois axes de recherche et leurs connexions .................................................................................. 69
Figure 5. Démarche scientifique de ré-ingénierie ................................................................................................ 70
Figure 6. Les cinq étapes de la méthodologie de recherche ................................................................................. 70
Figure 7. Contributions scientifiques relatives aux 3 axes de recherche.............................................................. 72
Figure 8. Axe « système », domaines de recherche supports, bilan des contributions et résultats....................... 73
Figure 9. Axe « système », domaines de recherche supports, bilan des contributions et résultats....................... 74
Figure 10. Axe « système », domaines de recherche supports, bilan des contributions et résultats..................... 75
Figure 11. Cartographie des principaux travaux de recherche............................................................................ 76
Figure 12. Axe « système », domaines de recherche supports, bilan des contributions et résultats..................... 78
Figure 13. Le système de conception .................................................................................................................... 78
Figure 14. Décomposition du système de conception ........................................................................................... 79
Figure 15. Les différentes étapes de la méthode GRAI Ingénierie........................................................................ 81
Figure 16. Modèle intégré IPPOP – Intégration des modèles Produit, Processus et Organisation..................... 87
Figure 17. Démarche effective de conduite de la conception ............................................................................... 88
Figure 18. Démarche de caractérisation et de mise en œuvre effective de la conduite de la conception............. 89
Figure 19. Axe « acteurs », domaines de recherche supports, bilan des contributions et résultats...................... 91
Figure 20. Coordination et analyse de la collaboration pour la gestion de projet............................................... 93
Figure 21. Modèle de collaboration en conception .............................................................................................. 95
Figure 22. Contexte du projet AGV7 .................................................................................................................... 98
Figure 23. Critères collaboratifs de l’évènement “definition besoin”, projet AGV7 ........................................... 99
Figure 24. Analyse de l’évènement “definition besoin”, projet AGV7 ............................................................... 100
Figure 25. Types de préconisations possibles pour améliorer la coordination .................................................. 101
Figure 26. Cartographie de mes apports scientifiques ....................................................................................... 102
Figure 27. Axe « environnements d’assistance », domaines de recherche supports, bilan des contributions et
résultats............................................................................................................................................................... 104
Figure 28. Diagrammes UML et démarche proposée illustrée pour la méthode GRAI Ingénierie .................... 106
Figure 29. Diagrammes UML et démarche de spécification conceptuelle ......................................................... 107
Figure 30. Diagramme des composants.............................................................................................................. 109
Figure 31. Exemple d’une interface graphique pour un acteur d’un centre de décision.................................... 110
Figure 32. Exemple d’IHM du prototype IPPOP : création de tâche................................................................. 110
Figure 33. IHM initiale du prototype ATLAS : page récapitulative des projets / tâches.................................... 111
Figure 34. Interactions entre l’environnement d’assistance et un acteur de la décision.................................... 114
Figure 35. Interactions entre un concepteur et l’agent produit associé ............................................................. 115
Figure 36. Cycle de vie du produit...................................................................................................................... 117
Figure 37. Arborescence produit multi-vues après personnalisation de Windchill ............................................ 118
Figure 38. Mécanisme de gestion de processus multi-niveaux flexibles ............................................................. 120
Figure 39. Décomposition de l’usage selon le triptyque Produit, Utilisateur et Environnement ....................... 123
Figure 40. Architecture du prototype ULM ........................................................................................................ 124
Figure 41. Ecran d’accueil du prototype ULM................................................................................................... 124
Figure 42. Diagramme de cas d’utilisation et besoins fonctionnels des acteurs ................................................ 126
Figure 43. Diagramme de classe de la structure produit et spécification de processus ..................................... 127
Figure 44. Diagramme état-transition de la classe « Document » ..................................................................... 127
Figure 45. Diagramme d’activités d’un processus de conception d’une pale .................................................... 128
Figure 46. Worflow, implémenté avec Windchill, du processus de conception d’une pale ................................ 128
Figure 47. Méthode de déploiement d’outils PLM en PME................................................................................ 130
Figure 48. Axe mise en œuvre d’environnements d’assistance et couplage des 3 axes de recherche................. 131
Figure 49. Evolution des axes de recherche ....................................................................................................... 138

Liste des tableaux

Tableau 1. Détail des enseignements en méthodes et outils pour la conception................................................... 19
Tableau 2. Détail des enseignements en gestion de projets .................................................................................. 20
Tableau 3. Détail des enseignements en ingénierie logicielle .............................................................................. 21
Tableau 4. Classification globale des connaissances en conduite de la conception............................................. 86

9
Rapport d’habilitation Christophe MERLO

10
Rapport d’habilitation Christophe MERLO

Glossaire

AMDEC : Analyse des Modes de Défaillances, de leurs Effets et de leur Criticité

BPR : Business Process Reengineering
CAD : Computer Aided Design
CAM : Computer Aided Manufacturing
CAE : Computer Aided Engineering
CAO : Conception Assistée par Ordinateur
CFAO : Conception et Fabrication Assistée par Ordinateur
CGP : Conception Généralisée de Produit,
l’une des 3 options du diplôme d’ingénieur ESTIA
CRM : Customer Relationship Management
CRT : Centre de Ressources Technologiques
CSCW : Computer Supported Cooperative Work
EDI : Electronic Data Interchange
ERP : Enterprise Resource Planning
FAO : Fabrication Assistée par Ordinateur
FUI : Fonds Unique Interministériel
GED : Gestion Electronique de Documents
IHM : Interface Homme-Machine
KBE : Knowledge Based Engineering
MDA : Model Driven Architecture
MDI : Model Driven Interoperability
MOCN : Machine Outil à Commande Numérique
MPA : Maitrise des Procédés Automatisés,
l’une des 3 options du diplôme d’ingénieur ESTIA
OGI : Organisation et Gestion Industrielle,
l’une des 3 options du diplôme d’ingénieur ESTIA
PDM : Product Data Management, SGDT en français
PLM : Product Lifecycle Management, ie Gestion du Cycle de Vie du Produit
PPO : Produit Processus Organisation
RDM : Résistance des matériaux SGDT
SADT : Structured Analysis and design Technics
SART : Structured Analysis for Real Time software
SGDT : Système de Gestion de Données Techniques
SIG : Système d’Information Géographique
TIC : Technologies de Information et de la Communication
UE : Unité d’Enseignement, spécifique au diplôme d’ingénieur ESTIA
ULM : Usage Lifecycle Management
UML : Unified Modelling Language

11
Rapport d’habilitation Contributions scientifiques Christophe MERLO

3. SYSTEMES D’INFORMATION SUPPORTS

AUX ACTEURS DE LA CONCEPTION
Mon parcours professionnel m’a dès l’origine entraîné vers l’enseignement avant de
s’orienter par la suite vers la recherche. Toutefois mes études ne m’avaient pas destiné à
une telle issue. Mon parcours est donc atypique dans la mesure où après une dizaine
d’années comme consultant en entreprise et enseignant dans des filières de 3e cycle, j’ai
passé un DEA puis une thèse de doctorat au sein du laboratoire LAPS de l’Université de
Bordeaux 1, thèse obtenue en 2003.
Mon positionnement s’est tout d’abord construit sur les bases de l’expérience acquise
comme consultant au CRT ILS, à travers des problématiques d’implantation de nouveaux
systèmes informatiques pour le développement de produits en entreprises et en particulier
en PME. Ce furent le plus souvent des outils de type CAO, mais aussi des outils FAO ou de
calcul numérique, avant l’arrivée des SGDT. Les secteurs d’activités de mes interventions
ont été très étendus puisque j’ai travaillé avec des entreprises de mécanique mais aussi des
entreprises de chaussure, de découpe de tissus, de design, de structures métalliques,
d’électrification… J’ai eu également à gérer des problématiques industrielles collectives dans
le domaine des échanges de données techniques et de l’implantation de nouvelles
technologies comme le prototypage rapide ou la numérisation de formes.
Avec l’expérience acquise année après année, il m’est apparu que les solutions qu’il était
possible de proposer aux entreprises étaient insuffisantes pour véritablement faire
progresser les entreprises. L’offre du marché me paraissait répondre à des besoins partiels
et à court terme et manquait de vision globale sur ce qui pouvait rendre plus performante
l’entreprise dans sa globalité. Cette insatisfaction m’a conduit à m’intéresser aux activités de
recherche : pouvoir appréhender les problèmes industriels avec un recul et une vision
d’ensemble m’ont semblé nécessaires pour apporter des solutions globales visant à
améliorer durablement les performances de l’entreprise. Mon DEA puis ma thèse m’ont alors
permis de passer une étape supplémentaire au cours de laquelle l’approche GRAI pour la
conception a fourni un cadre conceptuel et méthodologique servant de levier pour intégrer
différents points de vue essentiels pour maîtriser les processus de conception :
− la prise en compte du facteur humain et les mécanismes collaboratifs ;
− la coordination des projets et la prise en compte de la performance ;
− la caractérisation d’environnements d’assistance proactifs construits par une
approche de capitalisation des connaissances ;
− le déploiement de solutions en entreprise, comme l’étude des systèmes PLM.
La thématique de recherche que j’ai alors développée, « l’étude et la mise en œuvre
d'environnements d'assistance pour les acteurs de la conception, dans un contexte de
conduite de la conception », se trouve à la croisée de différents domaines comme la
modélisation d’entreprise, le management de projets, la conception de systèmes
d’information ou l’étude des facteurs humains. Dans une première section je poserai donc
les éléments sur lesquels reposent mes travaux de recherche et je préciserai la démarche

65
Rapport d’habilitation Contributions scientifiques Christophe MERLO

scientifique sur laquelle je m’appuie avant d’introduire brièvement mes différentes

contributions.
La seconde section de ce chapitre abordera de façon détaillée les différents axes de mes
travaux et contributions :
− l’axe « système » qui traitera de la conduite de la conception et de la méthodologie
GRAI Ingénierie ;
− l’axe « environnements d’assistance » qui se focalisera sur la proposition de
systèmes d’information pour la conduite et pour les acteurs de la conception ;
− et enfin l’axe « acteurs » qui traite du facteur humain et aborde l’étude des
mécanismes collaboratifs entre les acteurs de la conception.
Tout au long des résultats présentés, je tenterai de montrer comment ces différentes
contributions sont complémentaires et s’articulent pour répondre à une seule et même
problématique, celle de proposer des environnements informatiques qui vont permettre
simultanément d’améliorer la conduite des systèmes de conception et de favoriser la
collaboration entre les acteurs dans leurs activités métiers.
La troisième section viendra synthétiser ces éléments pour rappeler le schéma de
recherche global poursuivi et ouvrir sur les perspectives de nouveaux travaux qui viendront
compléter ce schéma de référence.
Enfin, dans cette première section où la problématique est posée, de nombreuses
références sont mentionnées chaque fois qu’est évoqué un élément développé soit dans les
sections scientifiques de ce chapitre, soit dans la liste détaillée de mes activités du chapitre
précédent.

66
Rapport d’habilitation Contributions scientifiques Christophe MERLO

3.1. CONTEXTE ET PROBLEMATIQUE

3.1.1. De la conduite des systèmes à la thématique de recherche

La conception est une phase essentielle du cycle de vie du produit [AFNOR 94]. De
nombreux travaux ont ainsi mis en évidence l’influence de la conception sur
l’industrialisation, les coûts et les délais de production [Clautrier 91] [Tichkiewitch et al. 93],
les efforts de commercialisation et les activités de maintenance, de service après-vente ou
de recyclage du produit en fin de vie. Selon [Baglin et al. 96], 75% des coûts du cycle de vie
d’un produit sont prédéterminés à la fin de la phase de conception et sont directement
imputables aux prises de décision qui ont eu lieu, et durant cette phase 40% d’économies
peuvent être réalisées. Améliorer la performance de ce processus d’ingénierie, c’est donc
avoir un impact important sur l’ensemble de l’entreprise. Pour cela, il faut pouvoir identifier
les éléments qui contribuent à sa performance. Plusieurs vecteurs d’amélioration sont ainsi
explorés tels que :
− à un niveau global : la rationalisation des processus eux-mêmes et l’organisation des
projets et des hommes, en vue de répondre à des objectifs clairement définis, en
s’appuyant sur des environnements informatiques supportant les flux d’information
correspondants,
− à des niveaux plus opérationnels : la coordination des équipes de concepteurs, la
prise en compte de leurs compétences et de leur évolution, le suivi de leurs activités
et la mise en œuvre d’outils facilitant leur coopération pour la génération et la maîtrise
de la connaissance nécessaire à la définition du produit.
Le pilotage de la conception est lié à cette recherche d’amélioration des processus
suivant des objectifs identifiés. Il implique la mise en place de critères d’évaluation en
fonction des points de vue adoptés vis-à-vis du processus. Mais si le pilotage se place au
niveau du processus, la conduite de la conception [Girard 99] se situe au niveau du système
de conception dans son ensemble et constitue une démarche globale d’amélioration
continue de ce système.
La notion de conduite de la conception est une notion très récente, postérieure à celle de
pilotage des systèmes de production et même de pilotage de la conception. L’élément
fédérateur de cette intégration est l’homme : créateur, acteur et décideur. Il apparaît dans de
nombreux travaux tels que ceux de [Lorino 96] où « piloter, c’est définir et mettre en œuvre
des méthodes qui permettent d’apprendre ensemble, d’agir ensemble de manière
performante, d’agir de manière de plus en plus performante ». C’est pourquoi notre réflexion
sera centrée sur l’homme et cette dimension intégrée dans nos investigations. La conduite
constituant une approche plus globale d’amélioration de la conception, le facteur humain est
là aussi essentiel : assurer le succès de cette démarche c’est « faire en sorte que chacun se
sente concerné, qu’il y ait adéquation entre les actions, les comportements et les objectifs de
l’entreprise » [Girard 99]. Afin de déployer la stratégie de l’entreprise auprès des acteurs, il
faut être capable d’évaluer la part de la valeur que devra atteindre le produit réalisé, et
mettre en évidence les liens causes-effets qui engendrent un niveau de performance de
façon à développer une capacité d’évaluation et de diagnostic (figure 1).

67
Rapport d’habilitation Contributions scientifiques Christophe MERLO

CONDUITE

Mesure,
Déploiement évaluation,
conduite diagnostic

ACTION

Figure 3. Liens entre stratégie et action

Dans ce cadre de conduite, il est indispensable pour les acteurs de la conduite de

disposer d’un retour informationnel portant sur les activités de conception afin de contrôler le
processus d’ingénierie [Eynard 99]. Toutefois ces acteurs doivent pouvoir considérer
l’ensemble des vecteurs d’amélioration potentiels afin de prendre les mesures favorisant la
performance du système de conception en fonction d’objectifs de conception clairement
identifiés. Pour atteindre ces conditions, il est nécessaire de proposer aux acteurs une
démarche opérationnelle qui les guide dans leurs activités de décision ainsi que les outils
leur permettant d’assurer ces activités. Ainsi les flux d’information entre les acteurs
supporteront le partage des informations pertinentes pour améliorer la performance du
processus d’ingénierie.

En ce sens nous entendons la conduite comme une approche globale qui permet de
mettre en évidence les éléments de la performance du système de conception dans son
ensemble. La conduite englobe les mécanismes de pilotage qui à différents niveaux et avec
plusieurs points de vue agissent sur ces éléments de performance [Lorino 96]. Proposer des
mécanismes de conduite d’un système, c’est en premier lieu modéliser ce système pour
savoir où porter le regard. C’est ensuite savoir décrire le fonctionnement du modèle afin de
déterminer sur quels facteurs agir pour le faire évoluer. Enfin, c’est aussi mettre en place des
outils méthodologiques et opérationnels capables d’exploiter le modèle en situation réelle.
Ma thématique de recherche s’intéresse à la mise en œuvre pratique de la conduite de la
conception : je m’intéresse donc au facteur humain à double titre. L’homme est à la fois le
moteur de la conception et doit être assisté par des outils lui permettant de remplir les
objectifs qui lui sont confiés, et à la fois une ressource qu’il faut conduire et piloter. L’étude et
la mise en œuvre d'environnements d'assistance pour les acteurs de la conception est donc
un objectif scientifique qui correspond dans le même temps à l’une des activités des acteurs
de la conduite de la conception. L'accent est donc mis sur l'étude sociotechnique des
processus de conception et sur la prise en compte des multiples facteurs venant influencer
les acteurs dans leurs activités.

Mon expérience industrielle passée m’a montré le besoin d’une approche globale et
fédératrice, c’est pourquoi je distingue trois axes complémentaires (figure 2) pour étudier et
proposer des environnements d’assistance :
− la prise en compte du système de conception dans son ensemble, de façon à étudier
les organisations et leurs impacts sur la conception : c’est l’axe « système » qui fait

68
Rapport d’habilitation Contributions scientifiques Christophe MERLO

appel à la systémique et à la modélisation d’entreprise, mais aussi aux aspects socio-

techniques liés aux relations entre les acteurs au sein d’équipes et de groupes et aux
compétences individuelles et collectives ;
− la proposition d’outils informatiques répondant à des besoins particuliers de
conception ou de systèmes d’information transverses destinés à accompagner la
conduite, qui doivent dépasser leur rôle traditionnel d’outils pour devenir une réelle
assistance à la conception : c’est l’axe « environnements d’assistance » ou outils ;
− l’étude des mécanismes collaboratifs entre les acteurs de la conception qui va
permettre aussi bien de formaliser et modéliser des connaissances et besoins pour
les autres axes mais aussi accompagner les acteurs dans leur intégration de
nouveaux outils méthodologiques ou logiciels : c’est l’axe des « acteurs ».
Ces trois axes complémentaires participent à ma thématique de recherche, « l’étude et
la mise en œuvre d'environnements d'assistance pour les acteurs de la conception,
dans un contexte de conduite de la conception », et permettent de structurer les travaux
poursuivis et les principales contributions qui en résultent.
Le premier axe et le troisième, étroitement liés, seront développés respectivement aux
§1.2 et 1.3, alors que le second axe, qui s’appuie sur les résultats des deux premiers axes,
sera traité dans le §1.4.

Axe Système

Axe Environnements d’assistance

Axe Acteurs

Figure 4. Mes trois axes de recherche et leurs connexions

3.1.2. La méthodologie de recherche suivie

Lors de ma thèse de doctorat j’ai intégré et appliqué la démarche de ré-ingénierie

préconisée par mon directeur de thèse, qui visait à distinguer l’approche du consultant, à
laquelle j’étais habitué, de l’approche du scientifique, que j’ai peu à peu acquise. Ce fut
l’objet de mon étude de cas (projet MMP, §2.3.3.1). Résumée dans la figure 3, cette
approche part du constat que la conduite de la conception relève de la recherche appliquée
et que nous ne pouvons progresser dans nos travaux qu’en travaillant avec et pour les
entreprises. Elle vise à étudier une problématique industrielle donnée non pas directement
mais en la généralisant par une modélisation adéquate et à la résoudre à ce niveau
générique avant d’appliquer les solutions dans le contexte spécifique de l’entreprise. Il faut

69
Rapport d’habilitation Contributions scientifiques Christophe MERLO

prévoir dans les solutions préconisées les mécanismes d’évaluation et d’évolution qui
permettront de faire évoluer dans le temps le système étudié.
OBJECTIFS

Modèles
Analyse Conception

Implémentation
Modélisation

?
Monde réel

Evolution

Système de conception existant Nouveau système de conception

Figure 5. Démarche scientifique de ré-ingénierie

La collaboration engagée avec Jérémy Legardeur lors de son post-doctorat en 2003 a

été l’occasion de réfléchir à cette approche à travers l’étude et la caractérisation de
mécanismes de coordination et de coopération dans les processus de conception. C’est
ainsi que nous avons formalisé une méthodologie plus précise. Notre démarche est basée
sur l'observation participante et sur la recherche-action en terrain industriel [Boujut & Tiger
02], ce qui sous-entend une présence sur le terrain importante, auprès des acteurs de la
conception. Elle se décompose en 5 étapes (figure 4) et a par exemple été mise en œuvre
dans des projets de recherche (thèse de G.Pol, §2.2.2) comme dans des projets industriels
(ISGA, §2.3.2) :

2. Caractérisation
1. Observation

5. Gestion du changement 3. Modélisation

4. Implémentation

Figure 6. Les cinq étapes de la méthodologie de recherche

1. Observation des pratiques et des activités dans des situations effectives de

conception en industrie, afin d'analyser les processus et de décrypter les
mécanismes sociotechniques entre acteurs dans la dynamique complexe des projets
de conception.
2. Caractérisation fine des processus de conception à partir des observations et en
tenant compte des contextes dans lesquels ils se déploient. Il s'agit de mieux

70
Rapport d’habilitation Contributions scientifiques Christophe MERLO

comprendre la nature de l'action collective en conception et d'identifier les premiers

paramètres et facteurs descriptifs des processus observés.
3. Formalisation des processus collaboratifs à l'aide de modèles qui décrivent les
phénomènes observés, mais qui tiennent compte du caractère peu prédictible et
donc peu stabilisé de l'activité des acteurs dans les organisations.
4. Instrumentation des processus collaboratifs en conception, sur la base des résultats
issus des deux premières étapes de notre méthodologie. Cette étape vise à proposer
de nouveaux dispositifs (outils, modèles, méthodes) afin d'améliorer les pratiques
observées.
5. Test et retour sur l'usage des outils, modèles, méthodes et des pratiques améliorées.
Cette mise en usage de nos propositions s'articule également autour d'une recherche
de dispositifs d'accompagnement au changement de façon à les pérenniser.
Pour chacun des trois axes précédemment identifiés, les travaux menés se sont appuyés
sur cette méthodologie et celle-ci guidera la présentation des principaux résultats. C’est cette
démarche que je préconise aux personnes, étudiants, doctorants ou partenaires de projet,
avec lesquelles je travaille et/ou que je supervise.

3.1.3. Les principales contributions

Avant de détailler les travaux menés, il est important de résumer brièvement les
principales contributions que j’ai pu apporter afin de faciliter la lecture des sections
suivantes. La figure suivante sera le support de ce résumé. Pour chaque axe, les
contributions sont réparties en fonction des différentes phases de la démarche scientifique
suivie. Les contributions les plus importantes sont indiquées sur fond grisé et les
contributions partielles sur fond à double barre.
Les contributions sont présentées axe par axe, et une figure synthétique conclut chaque
présentation d’axe.

71
Rapport d’habilitation Contributions scientifiques Christophe MERLO

Méthodologie GRAI Ingénierie

Modélisation du système de conception

Modélisation des connaissances
Audits Modélisation du système d’information
Interviews Implantation, Mise en
œuvre de la conduite

Méthodes pour la mise en œuvre d’environnements d’assistance

Méthode de spécification Architecture

Expertise métier conceptuelle Interopérabilité
Méthodes
Vue utilisateur d’implantation

Méthode d’analyse de la collaboration entre acteurs

Analyse des Capitalisation des

évènements bonnes pratiques
Observation collaboratifs
participante Réingénierie des processus
Gestion du changement

Figure 7. Contributions scientifiques relatives aux 3 axes de recherche

Contributions suivant l’axe « système » en conduite de la conception

La conduite de la conception [Girard 99] se situe au niveau du système de conception
dans son ensemble et constitue une démarche globale d’amélioration continue de ce
système. En ce sens elle englobe de nombreux aspects comme le pilotage du processus de
conception [Lorino 96] et la coordination de la conception [Coates et al. 00]. Les travaux
menés en conduite ont pour contexte la modélisation d’entreprise et la conduite des
systèmes [Doumeingt 84] via la méthode GIM, et poursuivent les travaux engagés par
[Girard 99] et [Eynard 99]. Les modèles élaborés par ces derniers posent les principes de la
conduite d’un système de conception et la nécessité de modéliser non seulement son
système décisionnel mais aussi son système technologique afin d’assurer la traçabilité des
informations produit et processus.

Contributions : méthodologie GRAI Ingénierie ; modélisation des

connaissances pour la conduite

Ma principale contribution porte sur la formalisation de la méthodologie GRAI Ingénierie

(figure 6) qui permet de rendre opérationnels ces principes en proposant une méthode de
déploiement de la conduite de la conception basée sur un ensemble de modèles. En
particulier j’ai proposé un modèle des connaissances nécessaires pour la conduite,
permettant aux acteurs de la conception et aux acteurs de la prise de décision d’appliquer
les mécanismes de conduite. Ce modèle s’appuie sur une représentation par niveaux de

72
Rapport d’habilitation Contributions scientifiques Christophe MERLO

complexité de type KADS [xxx] croisée avec une approche métier [Zacklad & Grundstein 01].
Ces contributions ont été validées par un projet industriel (MMP, cf §2.3.3.1). Un prototype
logiciel a également été mis au point pour étudier la faisabilité d’introduire des agents
logiciels (§1.4.2 et §2.2.5) dont le but est d’automatiser la gestion des connaissances au sein
d’un système d’information pour la conduite, permettant au système d’anticiper les besoins
métiers des utilisateurs.
La méthodologie GRAI Ingénierie impliquant la mise en œuvre d’un système
d’information adapté, elle s’est vue complétée par les travaux menés dans l’axe
« environnements d’assistance ». Le projet RNTL IPPOP (§1.4.3 et 2.3.2) a permis de faire
évoluer ces travaux : d’une part le modèle des connaissances a intégré les résultats des
laboratoires L3S (Grenoble), LASMIS (UTT), CRAN (Nancy) et LMP (Bordeaux) pour définir
un modèle intégré produit – processus – organisation ; d’autre part un prototype logiciel a été
développé pour démontrer la pertinence de la conduite de la conception. Enfin une méthode
opérationnelle de type « gestion de projet » a été définie pour utiliser le prototype IPPOP et
permettre la conduite au quotidien.

Méthode GIM Validation en entreprise (MMP)

Modélisation d’entreprises Projet RNTL IPPOP

Méthodologie GRAI Ingénierie Modèle intégré PPO

Modèles GRAI R&D Prototype logiciel IPPOP
Méthode de « gestion de projet »
Projet ANR ATLAS
Approche « Design co-ordination »
Modèle des connaissances
pour la conduite
Figure 8. Axe « système », domaines de recherche supports, bilan des contributions et résultats

Contributions suivant l’axe « acteurs » pour l’étude de la collaboration

L’étude des mécanismes collaboratifs entre les acteurs de la conception a permis de
développer plusieurs contributions. Cet axe est essentiel pour améliorer la mise en œuvre de
la conduite. En effet la conduite affecte les activités d’acteurs humains qui ne sont pas de
simples ressources : les gérer efficacement nécessite de bien comprendre et anticiper les
facteurs humains venant modifier l’impact de la prise de décision.

Contributions : méthode d’analyse des mécanismes collaboratifs entre acteurs

et de préconisations pour l’amélioration de la conduite ; modèles de
collaboration et de coordination

Devant le constat qu’aucune démarche permettant la prise en compte du facteur humain

n’existait, la principale contribution, élaborée dans le cadre de la thèse de G.Pol (rapport
HDR, §2.2.2), consiste dans la formalisation d’une méthode d’analyse entre acteurs. Basée
sur une approche socio-technique [Boujut & Tiger 02], elle vise à assurer la traçabilité des
évènements collaboratifs de façon à mettre en évidence les bonnes pratiques et
l’amélioration des dysfonctionnements constatés en vue d’accompagner le chef de projet
dans sa prise de décision [McMahon et al. 04]. Ces améliorations portent par exemple sur le
niveau de détail de représentation du processus de conception, sur la mise en évidence de
critères de décision pour les chefs de projets et sur la spécification de fonctionnalités
collaboratives pour les systèmes d’information de l’entreprise. Ces travaux ont été étendus
grâce au projet industriel ISGA (§2.3.2), qui a permis d’étudier l’impact des réseaux informels
d’acteurs sur la collaboration dans les projets.

73
Rapport d’habilitation Contributions scientifiques Christophe MERLO

Elaborée dans le cadre de la thèse de G.Pol (§2.2.2), cette méthode a été mise en
œuvre dans le cadre de projets menés avec l’entreprise EDERENA. La contribution
comporte la formalisation d’un modèle de la collaboration et d’un modèle pour la
coordination, destinés à assurer la capture des mécanismes collaboratifs, leur analyse et la
mise en œuvre des préconisations d’amélioration par les chefs de projet. Un logiciel, l’outil
CoCa, a été développé (§1.3.3 et §2.2.5) pour permettre l’utilisation effective de ces
modèles. Les résultats obtenus grâce à ces travaux ont été exploités dans les travaux de
l’axe « environnements d’assistance » : spécifications de processus au sein d’outils PLM
(§1.4.3), intégration de fonctionnalités collaboratives dans les prototypes logiciels pour la
conduite de la conception, …

Observation participante
Approches socio-techniques Validation en entreprise (EDERENA)

Capitalisation des bonnes pratiques Méthode d’analyse des mécanismes Outil CoCa
collaboratifs entre acteurs
Modélisation des connaissances
Modèle de collaboration
Conduite de la conception et de coordination
Systèmes PLM
Préconisations pour l’amélioration de la conduite
Préconisations pour la spécification de systèmes PLM

Figure 9. Axe « système », domaines de recherche supports, bilan des contributions et résultats

Contributions suivant l’axe « environnements d’assistance » supports à la

conduite et à la collaboration en conception
L’axe « environnements d’assistance », qui exploite les travaux menés dans les autres
axes, a donné lieu à plusieurs contributions. Les différents travaux engagés reposent sur
l’exploitation de plusieurs types de résultats portant sur :
− les approches orientées-objets [Booch, Quatrani 00] et les systèmes d’information
collaboratifs [Johansen 98] pour des travaux liés à la spécification d’outils ;
− les systèmes multi-agents [Ferber 97, Jennings et al. 98] pour des travaux faisant
appel à la gestion dynamique et collective des connaissances ;
− et les systèmes PLM [CIMdata, 03, Liu et al., 01] pour l’étude de ces outils.

Contributions : méthode de spécification d’environnements d’assistance pour

la conduite ; méthode de spécification et d’implémentation d’outils PLM

L’une des principales contributions, et à ce jour encore inachevée, porte sur la

formalisation d’une méthode générique destinée à spécifier et mettre en œuvre un
environnement d’assistance pour la conduite. Aujourd’hui n’a été formulée que la partie
amont, présentée à la section §1.4.1 : une méthode de spécifications couplée à la
méthodologie GRAI Ingénierie de façon à intégrer les besoins et modèles métiers issues de
la conduite. Elle a été appliquée dans le cadre du projet IPPOP, mais également lors du
développement du logiciel CoCa, du prototype logiciel impliquant des agents logiciels, et
actuellement dans le projet ANR ATLAS (§1.4.2 et §2.3.2).
Cette méthode a également été appliquée pour la spécification d’outils PLM et a été
couplée à la méthode d’analyse des mécanismes collaboratifs pour y intégrer les
améliorations et préconisations issues de l’observation directe des acteurs (thèse de G.Pol,

74
Rapport d’habilitation Contributions scientifiques Christophe MERLO

§). Il s’agit d’une contribution originale qui se veut être une alternative aux approches de type
« pattern » développées par exemple par [Gzara 05]. L’étude des systèmes PLM a permis
notamment de démontrer leurs limites en matière de conduite de la conception, tant au
niveau de la prise de décision et du pilotage du processus de conception, que des besoins
métiers des acteurs de la conception.

Contributions : principe technologique pour l’implémentation de mécanismes

de conduite dans les outils PLM ; modélisation des connaissances pour la prise
en compte des préférences utilisateurs en conception collaborative ;
intégration du concept ULM dans la gestion du cycle de vie produit

Suite à ce constat, plusieurs contributions venant compléter la méthode générique de

spécification et de mise en œuvre ont été réalisées :
− la proposition d’un mécanisme basé sur la technologie des workflows pour gérer des
processus multi-niveaux flexibles, en vue d’intégrer les mécanismes de pilotage au
sein des outils PLM ;
− l’intégration de la dimension utilisateur dans les outils méthodologiques et logiciels
des concepteurs par la modélisation de connaissances ‘a priori’ des préférences
utilisateurs (thèse de Livier Serna, §2.2.2) ;
− la proposition d’outils de capitalisation des usages du produit pour une exploitation ‘a
posteriori’ par les concepteurs : intégration du concept ULM (Usage Lifecycle
Management), développé par Emilie Chapotot, dans le contexte PLM.

Processus basé sur UML Projet IPPOP

Approches orientées-objet Projet ATLAS

Systèmes d’information collaboratifs Méthode de spécifications Outils CoCa, SIREP

Modélisation des connaissances conceptuelles Prototypes d’agents logiciels
Systèmes multi-agents
Modèle de collaboration
Modélisation d’entreprise et de coordination
Conduite de la conception
Mécanisme de gestion de processus
Méthode de spécifications multi-niveaux flexibles
Systèmes PLM
« Patterns » de processus et d’implémentation d’outils PLM
Maquettes Windchill
Besoins utilisateurs
Modélisation des connaissances
Modélisation des préférences utilisateurs
Concept ULM

Figure 10. Axe « système », domaines de recherche supports, bilan des contributions et résultats

Cette dernière figure permet d’illustrer la convergence récente des aspects

implémentation de systèmes d’information et l’étude des systèmes PLM, ce qui a entrainé la
définition de perspectives de recherche nouvelles et fédératrices (§1.5).

Ces travaux scientifiques ont également un impact dans le domaine de l’enseignement.

Plusieurs enseignements de dernière année (équivalant au Master 2) reprennent certaines
contributions : la méthode GRAI avec les étudiants de l’option Organisation et Gestion
Industrielle ; la conduite de la conception, les systèmes PLM et la modélisation des
connaissances avec les étudiants de l’option Conception Généralisée de Produits. Enfin, un

75
Rapport d’habilitation Contributions scientifiques Christophe MERLO

logiciel destiné aux étudiants a été développé en appliquant les contributions de

capitalisation des bonnes pratiques en conduite de la conception et de modélisation des
connaissances : il s’agit de SIREP, Système d’Information pour le Retour d’Expériences en
gestion de Projets.

La figure suivante résume l’ensemble des travaux menés : les thèses co-encadrées
personnellement ; les projets ayant directement contribué à mes propositions scientifiques
ou à leur validation (les projets dont j’avais la responsabilité entière ou d’un lot sont indiqués
d’un astérisque) ; les logiciels dont j’ai supervisé les spécifications et/ou le développement.
Il est important de rappeler que ces trois axes présentés séparément sont
complémentaires, les axes « systèmes » et « acteurs », bien que générateurs de
contributions spécifiques, supportent l’axe « environnement d’assistance » afin d’apporter
une réponse globale à ma problématique de recherche : « l’étude et la mise en œuvre
d'environnements d'assistance pour les acteurs de la conception, dans un contexte de
conduite de la conception ».
Apparaissent également dans cette figure les thèses démarrées récemment (M.Romain
et S.Mahut, §2.2.2) ainsi que les projets FUI ISTA3, et européens Mobyteam et Hobbyhorse,
qui seront évoqués en fin de chapitre dans les perspectives de recherche envisagées.

Axe Système de Thèse de doctorat

conception

Projet FUI
ISTA3 Logiciel
IPPOP
Thèse de Projet ANR
Etude M.Romain ATLAS*
Axe Environnements des Projet RNTL
d’assistance systèmes IPPOP Maquettes
PLM* Windchill
Thèse Agents
De Projet européen Hobbyhorse logiciels Thèse
L.Serna
Logiciel De
SIREP S.Mahut
Axe Acteurs et Logiciel Projet européen
Collaboration CoCa Mobyteam* Contrat ISGA*
Thèse de G.Pol / Projet Eitica EDERENA*

Méthodes d’analyse, Propositions Propositions de Méthodes et outils

observation de modèles méthodes et outils pour la mise en œuvre

Figure 11. Cartographie des principaux travaux de recherche

Après avoir synthétisé les principales contributions et résultats de mes travaux, les
sections suivantes développent successivement les 3 axes précédemment définis : l’axe
« système » de conception, l’axe « environnements d’assistance » et l’axe « acteurs ».

76
Rapport d’habilitation Contributions scientifiques Christophe MERLO

3.2. AXE SYSTEME : LA METHODOLOGIE GRAI INGENIERIE POUR LA

CONDUITE DE LA CONCEPTION

Mes travaux sur la conduite de la conception ont été menés en grande partie durant ma
thèse de doctorat. Ils s’inscrivent dans le cadre de l’approche systémique développée
historiquement au sein du groupe GRAI afin de modéliser les systèmes de production puis
plus récemment de l’équipe ICO (Ingénierie de la COnception) de l’IMS - LAPS. Les modèles
GRAI en conception [Girard 99] s’appliquent initialement au domaine de la conception
coopérative de produits manufacturés. Ils fournissent un cadre conceptuel destiné à
améliorer les performances de l’ingénierie et définissent un modèle de référence qui a pour
but d’étudier la conduite des systèmes de conception en s’appuyant sur la modélisation des
décisions et l’organisation du système opérant. Ce modèle du système de conception repose
sur la théorie des systèmes [Simon 60] [Le Moigne 77], la théorie des organisations
[Mintzberg 90] et la théorie des systèmes hiérarchisés [Mesarovic et al. 70]. Avant
d’approfondir mes contributions ces modèles sont à présent rappelés brièvement.

Contributions : méthodologie GRAI Ingénierie ; modélisation des

connaissances pour la conduite

Ma principale contribution porte sur la formalisation de la méthodologie GRAI Ingénierie

qui permet de rendre opérationnels ces principes en proposant une méthode de déploiement
de la conduite de la conception basée sur un ensemble de modèles. En particulier j’ai
proposé un modèle des connaissances nécessaires pour la conduite, permettant aux acteurs
de la conception et aux acteurs de la prise de décision d’appliquer les mécanismes de
conduite. Ce modèle s’appuie sur une représentation par niveaux de complexité de type
KADS [Schreiber et al. 94] croisée avec une approche métier [Zacklad & Grundstein 01]. Ces
contributions ont été validées par un projet industriel (MMP). Un prototype logiciel a
également été mis au point pour étudier la faisabilité d’introduire des agents logiciels dont le
but est d’automatiser la gestion des connaissances au sein d’un système d’information pour
la conduite, permettant au système d’anticiper les besoins métiers des utilisateurs.
La méthodologie GRAI Ingénierie impliquant la mise en œuvre d’un système
d’information adapté, elle s’est vue complétée par les travaux menés dans l’axe
« environnements d’assistance ». Le projet RNTL IPPOP a permis de faire évoluer ces
travaux : d’une part le modèle des connaissances a intégré les résultats des laboratoires L3S
(Grenoble), LASMIS (UTT), CRAN (Nancy) et LMP (Bordeaux) pour définir un modèle
intégré produit – processus – organisation ; d’autre part un prototype logiciel a été développé
pour démontrer la pertinence de la conduite de la conception. Enfin une méthode
opérationnelle de type « gestion de projet » a été définie pour utiliser le prototype IPPOP et
permettre la conduite au quotidien.

77
Rapport d’habilitation Contributions scientifiques Christophe MERLO

Méthode GIM Validation en entreprise (MMP)

Modélisation d’entreprises Projet RNTL IPPOP

Méthodologie GRAI Ingénierie Modèle intégré PPO

Modèles GRAI R&D Prototype logiciel IPPOP
Méthode de « gestion de projet »
Projet ANR ATLAS
Approche « Design co-ordination »
Modèle des connaissances
pour la conduite
Figure 12. Axe « système », domaines de recherche supports, bilan des contributions et résultats

3.2.1. Contexte initial : Représentation du système de conception

Le système de conception est décomposé en trois sous-systèmes (figure 11) :

− le système technologique, composé des hommes, des savoir-faire, des machines,
des logiciels et des flux d'information liée à la connaissance des produits. L'objectif
est de transformer les besoins exprimés (externes et internes) en la définition des
produits et de leurs procédés d'élaboration.
− le système décisionnel, en charge de la conduite de la conception, ayant pour rôle de
piloter le système technologique pour qu'il atteigne les objectifs de performances
fixés. Il a pour objectif d'élaborer les décisions fixant les ordres de gestion, appelés
aussi informations de pilotage, transmises au système technologique.
− le sous-système d’information permet de transmettre, traiter et mémoriser les
informations nécessaires. Il sert de liaison entre le système technologique et le
système décisionnel.

Objectifs

Information Système
s
externe Retour de
s Décisionnel l’information
Système Information (interne)
d’Information s
de pilotage
Expression Définition
Système du
du
besoin Technologique produit et des
procédés

Figure 13. Le système de conception

Dans les systèmes de conception, les événements surviennent à un instant quelconque.

Cependant, afin de maîtriser le flux transformé, il est nécessaire de scruter régulièrement
son évolution voire de planifier au mieux les événements. Dans la méthodologie GRAI
[Doumeingts 84], l'horizon H correspond à la durée de validité de la prise de décision et la
période P permet de remettre à jour (réactualiser) les informations support à la décision.
Suite à cette réactualisation, une remise en cause des décisions peut avoir lieu.
Ce concept d'horizon - période suggère une classification des décisions selon un premier
critère d'ordre temporel. Les décisions prises peuvent être classées en trois catégories
correspondant à trois niveaux temporels :

78
Rapport d’habilitation Contributions scientifiques Christophe MERLO

− les décisions stratégiques (long terme) concernent les politiques et les stratégies
définies. Elles indiquent les orientations et les objectifs de la conception.
− les décisions tactiques (moyen terme) concernent l'organisation et les moyens que
l'on va mettre en œuvre pour atteindre les objectifs.
− les décisions opérationnelles (court terme) concernent l'application, l'exécution des
différentes activités.
Pour mieux ordonner les décisions et faciliter la compréhension du pilotage du système
où s'opère la conception, un deuxième critère est nécessaire. Il correspond à la nature
même de la décision c'est-à-dire à son objectif fonctionnel. Ceci permet de structurer les
décisions à chaque niveau de décomposition temporel afin de satisfaire les objectifs de
pilotage et donc de synchronisation. Trois objectifs fonctionnels doivent être pris en
considération : les décisions liées à la gestion des flux d'informations, les décisions liées à la
gestion des capacités de l’entreprise (ou des entreprises partenaires) et les décisions de
synchronisation entre les flux et les capacités. On définit un centre de décision comme étant
une prise de décision d'un niveau donné (H - P) pour un objectif fonctionnel donné.
D’autre part, on considère deux points de vue complémentaires pour exprimer ces
différents objectifs fonctionnels : le point de vue « action » qui correspond à une démarche
d'ingénierie (pilotage des ressources de l'entreprise) et qui regroupe les décisions relatives à
la synchronisation de l'avancement des projets avec la disponibilité des ressources ; le point
de vue « objet » qui concerne strictement le produit (pilotage de la connaissance du produit)
et qui regroupe les décisions relatives à la synchronisation du déploiement des besoins avec
la définition de la connaissance sur le produit. La décomposition du système décisionnel en
centres de décision est représentée grâce à la structure GRAI R&D (figure 12).

Coordination entre
Synchronisation entre les niveaux
Synchronisation entre les
les fonctions fonctions
Plans objet
Plan action
GERER LA GERER LES
Infos CONNAISSANCE GERER LES Infos Infos GERER LES Infos
CONCEVOIR BESOINS INFOS PLANIFIER RESSOURCES
internes PRODUIT externes internes PROJETS externes
Stratégique
CENTRE DE
(H/P)
DECISION Lien informationnel

Tactique CENTRE DE
(H/P) DECISION
Cadres de
Opérationnel
décision
(H/P)

Cadre de Informations
conception de suivi

CENTRE DE
CONCEPTION
Flux d’information produit / processus

Figure 14. Décomposition du système de conception

79
Rapport d’habilitation Contributions scientifiques Christophe MERLO

La structure GRAI R&D permet d’identifier les différents niveaux décisionnels et leurs
interdépendances, et sert de support à la structuration du système technologique en centres
de conception. L’identification des centres de décision permet de décomposer le système
technologique en sous-ensembles désignés comme des « centres de conception »
autonomes selon des critères qui peuvent être d'ordre technique (exemple : décomposition
structurelle du produit), organisationnel (exemple : découpage par projet, création de
plateaux de conception) ou social (exemple : regroupement par compétence des acteurs).
Un centre de conception est une organisation qui a pour objectif de transformer les besoins
exprimés en la définition des produits et de leurs procédés d’élaboration. Ainsi, le système
technologique est structuré de façon dynamique pour un pilotage de chaque centre quel que
soit le niveau de granularité tout en assurant la coordination de l'ensemble.
[Eynard 99] démontre la nécessité pour les acteurs du système décisionnel d’exploiter
des connaissances relatives au produit et au processus. Pour le premier il propose un
modèle de produit dont l’objectif est de formaliser et de fédérer la connaissance relative au
produit. Pour le second il développe un modèle de processus assurant la traçabilité des
activités de la transformation de la connaissance produit réalisées par les acteurs du
système technologique.
De l’étude de ces modèles ont émergé 3 différents apports :
- la méthode GRAI Ingénierie, visant à rendre opérationnelle la modélisation
précédente, développée dans la section suivante,
- la modélisation des connaissances nécessaires pour la conduite,
- la conception d’un système d’information informatique destiné à supporter la conduite
de la conception tout au long du processus de conception.

3.2.2. Contribution : Méthode GRAI Ingénierie

L’objectif principal de cette contribution réside dans l’opérationnalisation des modèles

GRAI décrivant les principes de structuration et de conduite du système de conception pour
en améliorer la performance. La méthode GRAI Ingénierie [Merlo & Girard 03] constitue une
approche globale pour la modélisation des systèmes de conception et leur mise œuvre. Elle
a pour objectif d’amener l’entreprise à maîtriser ses processus de conception pour en
améliorer la performance. Cette méthode doit permettre d’élaborer les modèles de conduite
et d’organisation des systèmes technologiques mais également de spécifier le système
d’information afin de gérer les connaissances nécessaires à la conduite de l’ingénierie.
La méthode GIM (GRAI Integrated Method) [Zanettin 94] constitue le cadre initial à partir
duquel la méthode GRAI Ingénierie a été développée. Pour cela, GIM a été appliquée dans
deux cas d’étude industriels de façon à mettre en évidence ses points forts et ses points à
améliorer et ainsi définir GRAI Ingénierie. Nous distinguons trois phases essentielles (figure
13) :
− une phase d’initialisation,
− une phase de modélisation du système existant,

80
Rapport d’habilitation Contributions scientifiques Christophe MERLO

− une phase de conception comportant une étape de conception orientée utilisateurs,

puis une étape de conception orientée technique.

Système existant Initialisation

PHASE MODELISATION
Représentation du système étudié :
Vue fonctionnelle

Modélisation Modélisation Modélisation

du système du système du système
décisionnel technologique d’information

DIAGNOSTIC

PHASE CONCEPTION

Orientée utilisateurs
en harmonie avec
Conception Conception du
du système système Spécification
décisionnel technologique fonctionnelle
du système
Modélisation d’information
des
connaissances

Orientée technique Conception

progressive
du futur
système
Organisation, Ressources, Procédures d’information

Développement /
Acquisition puis
Nouveau système Implantation
Configuration et
Intégration

Figure 15. Les différentes étapes de la méthode GRAI Ingénierie

La phase d’initialisation implique les groupes de pilotage et de synthèse pour définir les
limites du système de conception étudié et les conditions de mise en œuvre de la méthode.
La phase de modélisation aboutit à la modélisation du système de conception actuel et
à son évaluation. L’organisation des projets et des hommes, les processus existants, les flux
d’information sont quelques-uns des éléments étudiés. L’analyse, menée par le spécialiste
GRAI en s’appuyant sur les modèles réalisés, porte sur le niveau de synchronisation et de
coordination au sein du système, comme sur l’homogénéité des processus et la cohérence
des flux d’information. Durant cette phase sont modélisés :

81
Rapport d’habilitation Contributions scientifiques Christophe MERLO

− la vue fonctionnelle du système de conception étudié. A l’aide du formalisme des

actigrammes on représente l’organisation existant au sein de l’entreprise pour le
développement des produits.
− le système décisionnel à l’aide de structures GRAI R&D. Plusieurs structures
peuvent être élaborées en fonction des différents types de projet menés dans le
système de conception. Chaque centre de décision est décrit via des réseaux GRAI.
− le système technologique à l’aide du formalisme des actigrammes étendus. Le
processus de conception est modélisé en distinguant les flux de données relatives
aux projets et les flux de données techniques relatives au produit. D’autre part les
processus sont étudiés à différents niveaux de granularité de façon à faire apparaître
le processus global de conception, les processus spécifiques à chaque projet, et les
processus élémentaires et répétitifs, donc automatisables (comme un processus de
validation, un processus de révision, un processus de suivi périodique, …).
− le système d’information à l’aide des modèles associés à l’approche informatique
privilégiée par l’entreprise (par exemple une approche comme Merise, ou une
approche objet basée sur UML).
Les modèles élaborés sont évalués par le groupe de synthèse et validés par le groupe de
pilotage. Le diagnostic est préparé par le spécialiste GRAI et élaboré avec le groupe de
synthèse. Il identifie les points forts et les points d’amélioration à apporter. Le groupe de
pilotage corrige éventuellement les objectifs initiaux avant d’engager la phase suivante.
La phase de conception prend en compte les résultats de l’analyse de la phase de
modélisation et les nouveaux objectifs assignés au système de conception afin de spécifier
le futur système de conception. L’étape de conception orientée utilisateurs intègre :
− la modélisation du futur système décisionnel :
o - la modélisation de structures GRAI R&D pour les différents types de projet
de conception à prendre en compte (routinier, innovant, …), en fonction des
objectifs relatifs aux orientations stratégiques de développement de produit.
o - la modélisation de chaque centre de décision à l’aide des réseaux GRAI.
− la modélisation du système technologique. Elle est établie en harmonie avec la
structuration du système décisionnel. En fonction de l’expérience acquise par
l’entreprise à propos du développement de ses produits, et au regard des nouveaux
objectifs assignés au système de conception, la pré-structuration du système
technologique en centres de conception est définie. Celle-ci n’est que partielle
puisqu’elle dépend directement de l’état d’avancement de la conception en cours de
projet. Les liens informationnels entre les centres de conception sont décrits et
lorsque cela est possible le déroulement de la conception au sein de chaque centre
de conception à l’aide des actigrammes étendus. Les cadres de conception entre
chaque centre de décision et les centres de conception qu’il pilote sont décrits.
− la modélisation des connaissances nécessaires pour que les acteurs du système de
conception puissent mettre en œuvre les nouveaux modèles du système décisionnel
et du système technologique. Compte tenu des principes induits par les modèles
GRAI et de la difficulté de cette étape, il est nécessaire d’accompagner cette

82
Rapport d’habilitation Contributions scientifiques Christophe MERLO

modélisation des connaissances en proposant au spécialiste GRAI un modèle

générique qu’il adapte au contexte industriel.
− la spécification du système d’information décrivant les fonctions à remplir par le
système d’information pour que les utilisateurs puissent réaliser leurs activités. Le
spécialiste GRAI s’appuie sur les autres modèles en cours d’élaboration pour
procéder à cette spécification.
La conception orientée technique spécifie de façon détaillée le nouveau système
d’information à partir de l’ensemble des spécifications issues de la conception orientée
utilisateurs. A ce titre le système d’information répond tout à la fois :
− aux besoins fonctionnels des utilisateurs relativement aux mécanismes issus des
modèles du système décisionnel et du système technologique, ce qui spécifie les
fonctionnalités et les traitements à remplir,
− aux besoins en gestion des connaissances, ce qui spécifie les informations à
exploiter et les traitements associés.

3.2.3. Contribution : Modélisation des connaissances pour la conduite

La méthode GRAI Ingénierie introduit le besoin de représenter les connaissances

nécessaires pour la conduite afin de prendre en compte les besoins des acteurs, tant les
concepteurs que les responsables, en matière de gestion et d’échanges d’information
relatives à la conduite. Pour cela nous avons procédé à l’analyse des activités de ces
acteurs pour identifier les connaissances mises en jeu [Baker 02, Ermine 01, Zacklad &
Grundstein 01]. Puis pour les représenter nous avons élaboré une modélisation par niveaux
de complexité. Enfin nous avons enrichi cette modélisation au cours de plusieurs projets
consécutifs. Par connaissances, il faut considérer les connaissances explicites (savoir) et les
connaissances implicites (savoir-faire).
Etude des activités des acteurs de la conception
Les centres de décision d’un même niveau décisionnel pilotent le système technologique
structuré en centres de conception. La figure 6 décrit les échanges entre les acteurs d’un
centre de décision et les acteurs d’un centre de conception [Girard 99], ce qui permet
d’identifier les principaux flux d’information.
L’analyse des flux d’information pour la conduite amène à identifier deux rôles principaux
pour les acteurs présents dans le système de conception l’un associé aux acteurs du
système décisionnel, le rôle « coordonnateur » et l’autre associé aux acteurs du système
technologique, le rôle « concepteur ». Ainsi [Poveda 01] distingue-t-il l’action du chef de
projet qui ordonne et arbitre l’action des concepteurs.
Le premier rôle « coordonnateur » est relatif à la prise de décision qui a lieu au sein du
système décisionnel. Ce rôle prend en charge les mécanismes liés à la conduite [Coates et
al. 00], à savoir :
− « coordonner » les projets de conception du système technologique par l’élaboration
de plans d’action visant à satisfaire les objectifs de conception. Cela se traduit par la
structuration du système technologique en centres de conception, la définition des

83
Rapport d’habilitation Contributions scientifiques Christophe MERLO

ressources humaines, matérielles, logicielles et informationnelles et la définition de

cadres de conception (objectifs de conception, contraintes, préconisations,
planification éventuelle) les pilotant,
− « assurer le suivi » de la réalisation des activités au sein des centres de conception
en vue d’en évaluer la performance, d’analyser les écarts avec les objectifs initiaux
puis de réorienter si nécessaire les actions en modifiant les plans d’actions d’action et
les cadres précédents.
Le second rôle « concepteur » est réservé aux acteurs impliqués dans un centre de
conception. Ce rôle consiste à prendre connaissance des informations contenues dans le
cadre de conception reçu et de réaliser les tâches nécessaires pour atteindre les objectifs
mentionnés, c’est-à-dire de formaliser de nouvelles connaissances relatives au produit et à
ses tâches pour en assurer la traçabilité. Un « concepteur » participe au suivi de ses tâches
en renseignant périodiquement les indicateurs de performance qui lui sont spécifiques.
Modèle générique des connaissances proposé
Une connaissance peut être représentée par un ensemble d’informations contextualisées
et objectivées [Link-Pezet 89]. Le « contexte » d’une information est donné par une série
d’informations permettant à son utilisateur d’en comprendre la signification en vue de
satisfaire les objectifs qui lui sont assignés. Une connaissance (pour un acteur) sera donc
formalisée par un ensemble d’informations (formalisées oralement ou physiquement) la
caractérisant et par les informations décrivant le contexte dans lequel elle a été générée
et/ou dans lequel elle est destinée à être exploitée. Les connaissances pour la conduite
regroupent plusieurs types de connaissances, aussi elles peuvent être exprimées à l’aide
d’informations hiérarchisées en trois niveaux (opérationnel, tactique et stratégique) selon leur
complexité :
− un premier niveau composé des connaissances élémentaires créées ou exploitées
par les acteurs pour atteindre leurs objectifs. Il est désigné niveau des
connaissances élémentaires, ayant un caractère opérationnel,
− un second niveau composé des connaissances qui expliquent comment les
connaissances précédentes ont été obtenues, soit en détaillant leur évolution, soit en
précisant les mécanismes mathématiques, logiques ou procéduraux appliqués. C’est
le niveau des connaissances de transformation, ayant un caractère tactique,
− un troisième niveau correspondant aux connaissances qui spécifient les
méthodologies et les principes à suivre, pour résoudre un problème donné et
conditionnant la mise en œuvre de connaissances de transformation. C’est le niveau
des connaissances d’expertise, ayant un caractère stratégique.
Sachant qu’une connaissance est rarement élémentaire, nous décrivons chaque niveau
de complexité à l’aide de deux sous-niveaux [Pun 99] permettant de décrire une
connaissance complexe à partir d’autres connaissances plus simples. J’ai proposé le méta-
modèle des connaissances suivant et caractérisé chaque niveau de complexité :
Soit Kni,j l’ensemble des informations représentant une connaissance Kn, de niveau de
complexité i, et d’occurrence j dans ce niveau,

84
Rapport d’habilitation Contributions scientifiques Christophe MERLO

Soit Opi-1,j l’opérateur associé à Kni,j et caractérisé par l’ensemble des informations de
niveau de complexité inférieur qui structurent Kni,j,
Soit Ci,j,k l’ensemble des liens référençant les informations partagées et décrivant le
contexte de Kni,j en vue d’en comprendre la signification,
Kni,j = (désignation, attributs, valeurs, Ci,j,k) (1)
et Kni,j = Opi-1,j (Kni-1,j’, …, Kni-1,j’’)
Où désignation : identifiant de la connaissance,
attributs : liste des informations spécifiques à la caractérisation de Kni,j
valeurs : liste valuant les attributs précédents
Ci,j,k : liste de k liens Ci,j,k traduisant les relations bidirectionnelles unissant
Kni,j à d’autres connaissances Knk’,k’’, de niveau k’ et d’occurrence k’’ qui en décrivent
le contexte :
Ci,j,k = { Knk’,k’’ }
Opi-1,j : opérateur Op, reliant une connaissance d’occurrence j du niveau de
complexité i à des connaissances de niveaux de complexité i-1 ayant participé à la
génération de Kni,j.
Opi-1,j caractérise comment une connaissance d’un niveau de complexité donné est
construite à partir des connaissances de niveaux de complexité inférieurs, et traduit les liens
sémantiques ayant une signification pour un acteur : relations de composition, de
transformation, de cause, … L’opérateur est un vecteur dont chaque composante s’applique
à une connaissance au moins. Ci,j,k définit un contexte induisant un sens particulier pour
l’information sur laquelle il s’applique. L’acteur peut alors manipuler cette connaissance.
Ci,j,k connecte des informations indépendamment de leur niveau de complexité. La
caractérisation d’un opérateur et des liens contextuels autorise plusieurs mécanismes
d’exploitation pour capitaliser, explorer et analyser les connaissances pour la conduite.
En se basant sur les mécanismes identifiés lors de l’analyse des activités des acteurs, on
peut considérer (tableau 1) les connaissances d’exploitation et les connaissances pour la
capitalisation à long terme. Les connaissances d’exploitation correspondent à une
capitalisation au fil de l’eau des informations indispensables pour assurer la conduite d’un
projet de conception. J’ai montré qu’elles sont structurées en quatre catégories associées
aux principales activités des acteurs puis en trois niveaux de complexité : coordination, suivi,
produit et processus.
Les connaissances pour la capitalisation à long terme sont également hiérarchisées en
niveaux de complexité mais elles forment un ensemble cohérent de connaissances
recouvrant les quatre catégories précédentes. Ces connaissances viennent aider les acteurs
dans les choix qu’ils ont à réaliser pour atteindre leurs objectifs et concernent aussi bien les
acteurs de la conduite que les acteurs de la conception. Le modèle proposé est
volontairement ouvert de façon à pouvoir évoluer par capitalisation des projets terminés.

85
Rapport d’habilitation Contributions scientifiques Christophe MERLO

Connaissances Suivi et
Coordination Produit Processus
Niveaux diagnostic
Déclencheur, Ressource,
Objectif, Ressource, Commentaire, Opérateur
1- Entité simple Modalité, Indicateur Indicateur
Information support
d’enchaînement,

EXPLOITATION
Information support

Cadre de décision, Cadre Fonction, Entité

2- Entité
de conception, Centre de Ecart Technologique, Entité Activité
complexe conception Frontière

3-Transformation Etat du modèle de

Plan de coordination Diagnostic Processus
simple produit

CAPITALISATION
4- Transformation
Règle de coordination Règle de conception
complexe

5- Expertise
simple Méthode de coordination Méthode de conception

6- Expertise
Conduite d’un système de conception
complexe

Acteur de la conduite Acteur de la conception

Tableau 4. Classification globale des connaissances en conduite de la conception

Le modèle des connaissances proposé intègre la possibilité de mettre en œuvre la

capitalisation à long terme des connaissances dans le futur système d’information. Trois
modes de capitalisation sont prévus :
− la capitalisation par l’exemple en permettant d’identifier des connaissances au fil de
l’eau comme représentatives d’une pratique « utile »,
− la capitalisation par généralisation en construisant de nouvelles règles génériques à
partir de ces connaissances au fil de l’eau,
− enfin la capitalisation externe basée sur des modèles théoriques traduits directement
sous forme de connaissances de capitalisation (méthode ou règle) via les opérateurs.
Ce modèle générique, proposé lors de ma thèse de doctorat n’a été qu’une première
étape avant de travailler à la mise en œuvre de ces travaux. Dans la section suivante, je
détaille les travaux réalisés en ce sens, qui ont abouti à la définition d’un modèle intégré
« opérationnel » et d’une méthodologie de conduite permettant aux acteurs d’exploiter ce
modèle pour la conduite des projets de conception au quotidien. Ces éléments sont
indispensables avant de procéder à la production d’un environnement logiciel visant à
assister les acteurs.

3.2.4. Contribution collective : Mise en œuvre de la conduite

Un modèle intégré pour l’amélioration des performances en ingénierie de la

conception
Ce modèle a été élaboré dans le cadre du projet IPPOP, dans la continuité de ma thèse
de doctorat. Le projet IPPOP (http ://www.opencascade.org/IPPOP/) a pour objectif
d’intégrer les connaissances liées au produit et au processus pour contribuer à

86
Rapport d’habilitation Contributions scientifiques Christophe MERLO

l’augmentation du patrimoine technologique de l’entreprise et à la maîtrise de la conduite de

l’activité de conception. Il s’inscrit dans une démarche d’intégration des dimensions Produit-
Processus-Organisation et d’extension des logiciels de CFAO et SGDT existants en prenant
en compte les aspects technologiques liés à la conception (environnement multi-acteur,
marché, ressources humaines et matérielles, gestion et capitalisation de la connaissance et
des savoir-faire, …).

ORGANISATION

PROCESSUS

PRODUIT

Figure 16. Modèle intégré IPPOP – Intégration des modèles Produit, Processus et Organisation

Les principaux objectifs de ce projet sont :

− intégrer les connaissances liées au produit [Roucoules & Tichkiewitch 02, Noel 05] et
au processus [Gero & Kannengiesser 06] pour contribuer à l’augmentation du
patrimoine technologique de l’entreprise et à la maîtrise de la conduite de l’activité de
conception,
− faire évoluer les outils de représentation du produit et de processus afin de supporter
la capitalisation des connaissances technologiques et leur exploitation lors de
nouveaux projets,

87
Rapport d’habilitation Contributions scientifiques Christophe MERLO

− développer et mettre en œuvre un environnement de travail adapté pour la

conception coopérative,
− permettre la gestion et la coordination de la conception concourante en vue de
l’amélioration continue des performances de l’ingénierie,
− fournir un démonstrateur.
A travers le projet IPPOP le modèle générique des connaissances a évolué pour
s’intégrer avec un ensemble de travaux portant sur la modélisation du produit et du
processus en vue de conduire efficacement le système de conception. Les évolutions portant
sur la dimension conduite du modèle générique, ré-intitulée « organisation », ont été limitées
et concernent essentiellement la nature des liens existant avec les dimensions produit et
processus. Le modèle global qui a été développé [Robin & Girard 06] (figure 14) regroupe
donc des éléments propres aux modèles de produit, de processus et d’organisation.

Entreprise

stratégique
Centre de
Décision
Cadre de
conception

Données
tactique Techniques Projet
Projet Données
Techniques

CD CD

DT DT DT
opérationnel SP1 SP2

T
T
T

Figure 17. Démarche effective de conduite de la conception

Afin de mettre en œuvre ce modèle intégré, une méthode a été élaborée pour la conduite
de la conception : l’enjeu scientifique consiste à s’appuyer sur la modélisation de l’entreprise,
de son organisation et de ses ressources, pour permettre la conduite effective des projets de
conception. En supposant que cette corrélation soit prise en compte, la conduite se traduit
par plusieurs niveaux d’action lors de la genèse puis du déroulement du projet de
développement de produit (figure 15) :
− après que le projet ait été initialisé et les objectifs globaux de l’entreprise spécifiés, le
chef de projet structure son projet en vue d’atteindre ces objectifs,
− il va donc définir plusieurs sous-projets pour lesquels il spécifiera à son tour des
objectifs, certains dédiés aux responsables (en tant que centres de décision locaux)
d’autres à l’ensemble des concepteurs impliqués, certains étant des objectifs de
performance,
− il associera des données techniques produit d’entrée nécessaires aux concepteurs
pour atteindre leurs objectifs, et des données techniques de sortie souhaitées et
correspondant à la réalisation de ces objectifs,

88
Rapport d’habilitation Contributions scientifiques Christophe MERLO

− il définira enfin une planification des tâches à mener, en précisant là encore leurs
objectifs et leurs données techniques,
− afin de permettre le suivi du projet, les concepteurs génèrent les données techniques
attendues et évaluent les indicateurs de performance qui leur sont demandés.
Cette démarche associée au modèle intégré assure de fait la prise en compte de
l’organisation de l’entreprise, la gestion multi-niveaux des projets, la différenciation entre les
décisions et la transformation de la connaissance produit-processus, la synchronisation des
flux informationnels multi- et inter-niveaux et enfin le suivi des projets.

En guise de synthèse partielle, différentes contributions ont été produites concernant

l’axe du « système de conception » (figure 16) : la méthodologie GRAI Ingénierie en
constitue l’armature et vise à mettre en œuvre la conduite de la conception au sein de
l’entreprise en vue d’améliorer ses performances pour le développement de produits. A
travers la démarche scientifique décrite initialement, des modèles ont été proposés pour
représenter le système de conception (phases de modélisation du problème puis proposition
de solutions génériques) ainsi qu’une modélisation générique des connaissances pour la
conduite. Cette modélisation a permis d’élaborer le modèle PPO (Produit-Processus-
Organisation), support au développement de prototypes logiciels (phase d’implémentation de
ces solutions et de déploiement). La méthodologie GRAI Ingénierie inclut des tâches de
spécification et de développement du système d’information support à la conduite, qui sont
développées dans le chapitre 3.3.

Observation Modélisation Formalisation Déploiement

Analyse solutions

Axe
Méthodologie GRAI Ingénierie
Système
Réseaux GRAI Actigrammes
Structure GRAI R&D

Modélisation du système de conception

Modélisation des connaissances
Audits Modélisation du système d’information
Interviews Implantation, Mise en
œuvre de la conduite
Modèle intégré Approche UML
Produit-Processus-Organisation
Méthode effective
de conduite

Figure 18. Démarche de caractérisation et de mise en œuvre effective de la conduite de la conception

Les modèles élaborés (contribution importante repérée par un fond uni dans la figure 12)
ont permis d’obtenir une représentation précise du système de conception, des
connaissances mises en jeu et des flux d’information entre deux catégories d’acteurs : les
responsables en charge de la coordination et les concepteurs en charge de la conception.
Toutefois il a été clairement établi que le sous-système technologique, en correspondance
avec la nature non prévisible du processus de conception, ne peut pas être complètement
modélisé. Par conséquent, les flux d’information mis en jeu ne prennent pas en compte la
totalité des flux échangés entre les concepteurs. Les spécifications que nous avons pu
élaborer restent des spécifications génériques permettant de gérer des connaissances
« types » et des échanges « habituels » et ne rendent pas compte de besoins spécifiques
liés aux actions réelles des acteurs de la conception quand ils sont impliqués dans un

89
Rapport d’habilitation Contributions scientifiques Christophe MERLO

processus de conception non routinier. C’est pourquoi la contribution concernant le

déploiement effectif des mécanismes de conduite reste partielle à ce jour (fond maillé sur la
figure 16).
J’ai alors abordé la question de la collaboration entre les concepteurs en posant comme
hypothèse qu’une meilleure connaissance des mécanismes collaboratifs entre les acteurs
permettrait d’identifier des bonnes pratiques exploitables par le chef de projet et les
responsables pour améliorer la façon dont ils assuraient la conduite de la conception. C’est
cette thématique que j’aborde dans la section suivante.

90
Rapport d’habilitation Contributions scientifiques Christophe MERLO

3.3. AXE ACTEURS : L’ETUDE DES COLLABORATIONS ENTRE ACTEURS

Menés principalement lors des travaux de thèse de Guillaume Pol en coopération avec
l’Université de Cranfield (UK), les principaux résultats de l’axe « des hommes », consacré à
l’étude de la collaboration entre les acteurs [Brissaud & Garro 98], s’appuient directement sur
la méthodologie de recherche présentée au §1.1.2. Dans une première section cette
approche sociotechnique permet d’élaborer une démarche complète permettant d’assurer
l’analyse des mécanismes collaboratifs entre acteurs impliqués dans le développement de
produit, l’amélioration des dysfonctionnements constatés et la capitalisation des bonnes
pratiques en vue d’accompagner le chef de projet en charge de la conduite de la conception
[McMahon et al. 04]. La deuxième section précise les modèles de connaissances sur
lesquels est basée cette démarche et pour lesquels il a été nécessaire de développer un
logiciel pour la capture et l’analyse des mécanismes collaboratifs, ce logiciel est présenté
dans la troisième section.

Contributions : méthode d’analyse des mécanismes collaboratifs entre acteurs

et de préconisations pour l’amélioration de la conduite ; modèles de
collaboration et de coordination

Pour mener à bien la caractérisation de cette démarche, j’ai noué un partenariat de 2004
à 2007 avec la société Ederena Concept, PME concevant des produits à base de structures
en nid d’abeille, afin de répondre à ses besoins de rationalisation de ses flux d’information en
conception et industrialisation. Un travail d’observation sur le terrain a permis de participer
aux travaux menés en interne dans l’entreprise pour atteindre cet objectif, d’étudier de façon
très précise l’organisation des activités de conception et d’approfondir le rôle du chef de
projet. Un travail plus spécifique de maquettage d’un outil de SGDT a été réalisé pour étudier
son apport dans la rationalisation des flux d’information. Cette action s’est poursuivie par une
analyse plus fine des activités de collaboration en vue de les capitaliser pour le chef de
projet et de lui permettre de déterminer les différents niveaux de flexibilité du processus de
conception qu’il doit coordonner. Cette étude complémentaire, soutenue par le pôle régional
EITICA, a abouti à la réalisation d’un outil informatique d’analyse des événements
collaboratifs que nous avons nommé CoCa (Collaborative Capture).

Observation participante
Approches socio-techniques Validation en entreprise (EDERENA)

Capitalisation des bonnes pratiques Méthode d’analyse des mécanismes Outil CoCa
collaboratifs entre acteurs
Modélisation des connaissances
Modèle de collaboration
Conduite de la conception et de coordination
Systèmes PLM
Préconisations pour l’amélioration de la conduite
Préconisations pour la spécification de systèmes PLM

Figure 19. Axe « acteurs », domaines de recherche supports, bilan des contributions et résultats

91
Rapport d’habilitation Contributions scientifiques Christophe MERLO

3.3.1. Contribution : Méthode d’analyse des mécanismes collaboratifs

En gestion de projet, le suivi de l’avancement de processus de conception peut être

défini comme la compréhension des situations de conception existantes en vue de les
évaluer et de prendre les décisions qui modifieront et amélioreront le processus à venir en
fonction des objectifs fixés par le client ou déterminés par la stratégie de l’entreprise
[Baumberger et al. 2003]. Le contrôle du projet se ramène donc à un problème de prise de
décision visant à supporter les concepteurs dans leurs activités [Girard and Doumeingts 04]
pour satisfaire les objectifs initiaux (figure 11).
Pour cela les chefs de projet ont besoin d’identifier les leviers d’action sur lesquels ils
pourront agir, et en particulier ceux qui vont influencer la collaboration pour améliorer la
performance de la conception. Un chef de projet dispose aujourd’hui d’un ensemble vaste de
critères pour prendre en compte tous les aspects d’un projet comme les étapes du
développement du produit, les objectifs du client et les livrables, les tâches et la planification,
les compétences des experts, les motivations et les enjeux collectifs ou individuels, les
méthodes et outils collaboratifs et aussi des objectifs individuels et collectifs concourants.
[Perrin 99] pose « la conception comme lieu de construction d’une intelligence
collective ». La coopération dans les activités de conception est désormais essentielle pour
la performance et la compétitivité des firmes innovantes. A travers une amélioration de la
collaboration et de la communication entre les acteurs, est recherchée l’émergence de
nouvelles idées voire d’innovations, de flexibilité dans les processus standardisés de
conception ou d’enrichissement des compétences de chacun. Néanmoins les paramètres
pour influencer la « qualité » de la collaboration restent flous et difficiles à caractériser.
L’existence de relations informelles est essentiel dans une PME car les acteurs ont
besoin de pouvoir collaborer afin d’être réactifs et flexibles en fonction des demandes et des
problèmes rencontrés. Bien souvent ce cadre informel s’accompagne de faibles contraintes
« procédurales » et d’une charge de travail très importante liée au partage de multiples
responsabilités et au cumul de tâches officielles et de tâches informelles. Généralement les
projets sont caractérisés par des jalons à respecter, ce qui priorise nécessairement les
tâches et les fournitures. Paradoxalement, le processus de développement d’un produit est
très formalisé à un niveau macro, par la définition d’étapes et de jalons à respecter, alors
qu’au quotidien la planification se révèle très flexible, voire parfois réalisée seulement à court
terme. Cette situation favorise les mécanismes collaboratifs. L’une des difficultés du chef de
projet est donc de prendre en compte ces mécanismes dans sa gestion de projet sans
bouleverser ce fragile équilibre entre prescrit et émergent. Là encore, malgré de multiples
travaux sur la collaboration en conception [De Vreede and Briggs 2005], peu de règles ou de
principes opérationnels pour la gestion de projet n’ont été définis pour aider ces chefs de
projet dans leur travail quotidien.
C’est pourquoi j’ai choisi de développer cette démarche d’analyse de la collaboration et
de capitalisation des connaissances pour apporter un appui sur le long terme au chef de
projet, et lui permettre de caractériser progressivement ses propres règles et principes. Ce
faisant, ce sont les compétences du chef de projet qui sont améliorées plus rapidement via
l’application de cette démarche. Celle-ci s’inscrit dans le cadre de la conduite de la
conception (figure 11) puisque la prise de décision du chef de projet intervient pour assurer

92
Rapport d’habilitation Contributions scientifiques Christophe MERLO

la conduite, c’est à dire la « coordination » des concepteurs qui, dans le système

technologique, « collaborent » pour transformer la connaissance relative au produit et au
processus. L’objectif est d’améliorer la coordination par le chef de projet par une meilleure
compréhension et une meilleure connaissance des mécanismes collaboratifs.
La démarche « d’étude de la collaboration » (figure 18) repose sur la caractérisation d’un
modèle de collaboration qui doit permettre de recenser l’ensemble des mécanismes
collaboratifs existants lors d’un projet de conception de produit, à l’aide d’un logiciel support
dénommé CoCo (Collaborative Capture). Elle se compose des étapes suivantes :
− L’observation participante des projets de conception par un expert en vue de collecter
des données relatives aux évènements de type collaboratifs, recueillis à l’aide de
l’outil CoCa.
− L’exploitation de ces données pour une analyse approfondie et une première
évaluation des évènements collaboratifs et des liens qui existent entre certains de
ces évènements.
− La formalisation de diagnostics sur la collaboration effective, les écarts constatés
entre ce qui était prévu par le chef de projet (coordination) et ce qui a été constaté, de
façon à faire apparaître des éléments de « bonne pratique » ou des points à
améliorer.
− La génération de propositions pour un retour vers la coordination. Ces retours sont
formalisés sous forme de préconisations pour le chef de projet en vue d’anticiper sur
de futures situations de conception ou d’améliorer la coordination de nouveaux
projets. A ce jour les expérimentations menées ont permis de déterminer trois types
de préconisations possibles qui seront développées dans le §1.3.3.

Objectifs

Evaluation des
performances
réalisées Préconisations

Actions Définition ETUDE DE LA COLLABORATION

correctives des écarts
Préconisations
Prise de Informations Données Diagnostics
décision de suivi CoCa collaboration
& coordination
Analyse de la
collaboration
Formalisé Planifié

ENTREES SORTIES

Besoins, Description du produit,

Emergent Flexible
Spécifications, Plans,
Contraintes Instructions de fabrication
et d’utilisation

Figure 20. Coordination et analyse de la collaboration pour la gestion de projet

93
Rapport d’habilitation Contributions scientifiques Christophe MERLO

3.3.2. Contribution : Un modèle pour l’analyse de la collaboration

Le modèle de collaboration qui a été proposé pour permettre une capitalisation et une
analyse a été construit à partir de deux points de vue complémentaires : le point de vue de la
conduite, puis le point de vue des facteurs humains.
Du point de vue de la conduite, la collaboration résulte des conditions que le pilotage des
activités définit et met en place pour les concepteurs : la définition d’objectifs et de tâches,
leur planification et la définition de jalons et de livrables. Du point de vue humain, la
collaboration peut être définie comme basée sur les relations et les interactions entre acteurs
impliqués dans un évènement collaboratif, et la réalité de cette collaboration repose sur leurs
compétences mais aussi leurs motivations et leurs capacités de communication. De fait ces
deux points de vue doivent être pris en compte pour pouvoir identifier les multiples facteurs
qui influencent la collaboration et ainsi caractériser les évènements collaboratifs. Cette
caractérisation est une étape indispensable avant de pouvoir analyser et comprendre ce qui
s’est passé. Ainsi doit-on pouvoir répondre à des questions telles que : les acteurs ont-ils
œuvré à distance ou étaient-ils physiquement dans la même pièce ? étaient-ils présents en
même temps lors de cet évènement ou bien leur action résulte-t-elle d’actions individuelles
successives, et éventuellement avec des échanges d’information entre ces actions ? ces
actions ont-elles été prévues, voire planifiées, par le chef de projet ? Tous les facteurs ainsi
identifiés doivent pouvoir servir à caractériser les évènements collaboratifs et l’ensemble de
ces informations doit pouvoir être conservé via un outil informatique.
Le modèle de collaboration doit répondre à ces besoins d’identification, de
caractérisation et de traçabilité, puis il doit permettre d’en mener l’analyse. Pour assurer la
traçabilité de la collaboration, l’hypothèse retenue est celle de l’observateur qui suit le projet
de conception et qui identifie lui-même les actions de type collaboratives. Comme au
moment de l’identification l’observateur n’a pas encore le recul nécessaire, les actions
collaboratives prises en compte sont celles qui impliquent effectivement des interactions
(deux acteurs en discussion par exemple) mais aussi celles qui génèrent potentiellement des
interactions sous forme d’échanges d’informations de tout ordre (par exemple la
transmission d’un livrable par mail avec des commentaires précis). L’hypothèse d’une
traçabilité acquise de façon automatique ou semi-automatique n’a pas été retenue pour deux
raisons principales :
− Beaucoup de collaborations, notamment émergentes ou spontanées, sont basées sur
des interactions directes entre acteurs, sans support informatique qui permettrait une
capture initiale automatique.
− Une saisie par les acteurs eux-mêmes à partir d’une planification initiale entraîne une
surcharge de travail pour ces acteurs, un appauvrissement des actions tracées car
elles privilégient les actions prévues par rapport aux actions émergentes, et enfin un
biais important de la part des acteurs quant aux situations difficiles mais aussi les
plus intéressantes.
Le modèle de connaissances (figure 19) pour la collaboration est donc construit autour
du concept d’évènement, et en particulier d’évènement collaboratif. L’observateur capture
une succession d’évènements situés dans le temps en vue de les comparer ultérieurement
aux différents processus de conception prévus et réactualisés. De cette confrontation des

94
Rapport d’habilitation Contributions scientifiques Christophe MERLO

améliorations relatives à la conduite des projets doivent être formalisées à destination du

chef de projet.

Figure 21. Modèle de collaboration en conception

La caractérisation des évènements collaboratifs s’appuie sur plusieurs connaissances

identifiées lors de nos travaux sur la conduite, sur la collaboration, sur les environnements
de Travail Coopératif (CSCW, Computer Supported Cooperative Work), et sur le terrain en
PME. Chaque évènement collaboratif est caractérisé par :
− un contexte global lié au projet, en vue de comprendre dans quel environnement cet

95
Rapport d’habilitation Contributions scientifiques Christophe MERLO

évènement a-t-il lieu : c’est la classe ‘ProjectContext’. Elle comporte un mécanisme

de versionnement qui permet de faire évoluer le contexte du projet dans le temps,
comme lors d’une modification de la demande du client ou un changement de
stratégie interne à l’entreprise.
− une définition initiale, par la classe « EventActivity » et la classe « Event », de nature
plutôt quantitative : la désignation, la date d’occurrence, les acteurs impliqués,
éventuellement sa durée et/ou la date prévue, l’objectif de cet évènement, son
importance, le résultat attendu et la décision prise, et des commentaires libres. Un
évènement peut donc ici représenter des actions ponctuelles et spontanées de courte
durée comme l’envoi d’un mail, ou de plus longue durée comme une discussion à la
machine à café, mais aussi des tâches planifiées comme des réunions de travail ou
un jalon de validation.
− des critères, par la classe ‘CollaborativeCriteria’, visant à formaliser la façon dont la
collaboration s’est déroulée d’un point de vue plus qualitatif : la localisation (même
lieu ou lieu différent), la temporalité (en même temps ou à des moments différents), le
niveau de prescription, le niveau de planification et le niveau de formalisation via un
support (téléphone, papier, outil informatique, méthode spécifique…). Pour compléter
ce type d’information, la classe ‘ActivitySubject’ permet de caractériser le type
d’action réalisée pour la situer dans le processus de conception (action plutôt
préparatoire comme un rapport ou de la planification, de contrôle comme une
validation ou un jalon, ou plutôt technique comme une action de conception ou
d’industrialisation). La classe ‘subject’ permet enfin d’indiquer la nature de cet
évènement : réunion physique, discussion, vidéo-conférence, coup de téléphone, etc.

Après cette première caractérisation, l’observateur peut associer à l’évènement capturé :

− une évaluation via la classe ‘evaluation’ plus personnelle : le temps perçu par les
acteurs, qui peut parfois signifier qu’une action a été peu productive ou au contraire
très riche et efficace ; la difficulté technique qui peut compenser ou amplifier
l’impression donnée par le temps perçu ; et le niveau d’utilité qui permet d’évaluer si
le résultat obtenu est plutôt pertinent et contribue à faire progresser le processus de
conception.
− l’analyse elle-même, via la classe ‘analysis’, qui comporte une partie libre mais aussi
quelques éléments identifiés basés sur des critères entièrement qualitatifs de la part
de l’observateur : la « qualité » des relations entre les acteurs, la « qualité » de la
productivité atteinte pendant l’évènement, « l’ampleur » de la communication entre
les acteurs, la motivation « ressentie », à moduler avec la présence de plusieurs
« niveaux hiérarchiques » parmi les acteurs, ou le « niveau de confidentialité » requis.
Ces connaissances résultent d’une analyse personnelle et sont potentiellement
porteuses de controverses. Pour cette raison leur utilisation devra être limitée et leur
accès contrôlé.
− des liens de différentes natures (classe ‘Link’) : des liens temporels, de type cause à
effet, … qui participent à la compréhension des mécanismes collaboratifs, à la
justification de certaines anomalies ou à la formulation de bonnes pratiques.

96
Rapport d’habilitation Contributions scientifiques Christophe MERLO

Les premières expérimentations menées ont mises en évidence la nécessité de corréler

les connaissances issues de la capture et l’analyse des évènements collaboratifs avec les
connaissances nécessaires à la coordination. En particulier les successions d’évènements
tracés n’ont pas tous le même niveau de granularité quand ils sont comparés au processus
de conception [Gonnet et al. 07] : ainsi une succession de mails et de coups de téléphone
puis la rédaction d’une note interne, peut correspondre à une tâche identifiée dans le
processus de conception et qui met en évidence des paramètres jusqu’alors ignorés ou non
formalisés. Le modèle de collaboration initiale a donc été enrichi de la classe ‘activity’, dotée
des mêmes caractéristiques qu’un évènement, pour regrouper des évènements au sein
d’activités, elles-mêmes pouvant être groupées à un niveau supérieur afin de caractériser les
différents niveaux de granularité requis par l’analyse.
Par ailleurs les évènements collaboratifs tracés permettent de caractériser des
séquences de tâches qui peuvent être réutilisée par le chef de projet comme des processus
élémentaires ou des processus types directement lors de sa planification. Pour cette raison
plusieurs activités peuvent être reliées via la classe ‘process’, autorisant ainsi l’identification
dans le projet d’un processus de conception structuré en sous-processus, puis en activités et
enfin en évènements.
Ce modèle de collaboration permet donc de gérer la totalité des connaissances
nécessaires à la capture, la compréhension et l’analyse des évènements collaboratifs, ainsi-
que leur exploitation en vue de formaliser sous forme de processus les bonnes pratiques lors
des projets de conception, en vue de leur utilisation par les chefs de projet. Ce modèle
nécessite l’intervention d’un observateur expert neutre pour permettre une formalisation
fiable des connaissances et une exploitation collective et non individualisée des informations
saisies. Un outil logiciel est nécessaire pour permettre d’exploiter ce modèle au vu de la
quantité d’évènements identifiables lors d’un projet de conception. C’est l’objet de la section
suivante.

3.3.3. Contribution : Un outil support, CoCa

L’outil logiciel CoCa a été développé en vue de supporter la capture des évènements
collaboratifs émergents lors du développement d’un produit et de faciliter l’analyse des
données récoltées pour formaliser des préconisations à destination des chefs de projets.
Il est donc destiné à être utilisé par un observateur-analyste, impliqué dans les projets de
conception pour être dans l’action, mais externe à l’équipe de conception pour conserver sa
neutralité autant que possible.
Développé en langage Java et avec une base de données relationnelle accessible en
réseau, l’interface utilisateur se répartit entre trois fonctionnalités complémentaires : la
gestion des projets, la gestion des évènements collaboratifs, la visualisation des données
collectées.
Après un écran de connexion, l’analyste accède à un écran précisant la liste des projets
en cours. Il peut créer un nouveau projet, modifier un projet existant ou sélectionner un projet
existant pour accéder aux fonctionnalités relatives aux évènements collaboratifs. Modifier un
projet revient à modifier le contexte de ce projet, c’est-à-dire les paramètres qui caractérisent

97
Rapport d’habilitation Contributions scientifiques Christophe MERLO

ce projet (figure suivante). L’analyste a la possibilité d’écraser les paramètres précédents

(modification mineure) ou de générer une nouvelle version du contexte projet si ces
modifications coïncident avec un changement d’orientation des objectifs stratégiques du
projet. La liste des évènements correspondant au projet ou à la version du contexte est
également affichée afin d’obtenir une vision d’ensemble du projet.
Les fonctionnalités dédiées aux évènements collaboratifs sont regroupées à travers un
écran « event » qui synthétise à la fois les fonctions pour la capture et les fonctions pour
l’analyse (figure suivante). La capture comprend plusieurs onglets permettant de caractériser
un évènement : le ‘contexte’ de l’évènement, le ‘type et le sujet’ et les ‘critères’ de mesure.
L’analyse est saisie à travers les onglets ‘liens’ entre évènement puis ‘évaluation/analyse’.
Enfin les fonctionnalités de visualisation proposent aujourd’hui une représentation
graphique de l’enchainement des évènements basée sur un critère temporel et/ou causal
et/ou problème. A terme il est envisagé d’adjoindre un module statistique permettant
d’obtenir des synthèses issues des paramètres de caractérisation des évènements, et ce en
cumulant les données de plusieurs projets.
L’outil CoCa a été expérimenté au sein de la PME Ederena Concept sur 3 projets
différents, cumulant ainsi une centaine d’évènements collaboratifs.

Calcul Ingé Calcul

Qualité Resp Qualité
Conception Dessinateur

3 demandes du client : bonnet, pentographe, acrotère.

Le prototype, nommé Pegase, doit être achevé fin 2006.
La série, nommée AGV7, doit être achevée début 2007.
L’offre doit être réalisée pour le 27 février 2006

Définition besoin Problème, cause-effet

PAT Cause-effet
Planning
Conception pièce
Conception Outill.
Visite client 1 Cause-effet
Visite client 2

Figure 22. Contexte du projet AGV7

98
Rapport d’habilitation Contributions scientifiques Christophe MERLO

La figure 20 présente le contexte du projet AGV7, projet extrêmement important pour

l’entreprise car en liaison avec un donneur d’ordre du secteur ferroviaire. La liste des
évènements montre la définition de liens de type causalité et problèmes sur 3 évènements,
reconstituant ainsi une séquence d’évènements dont le dernier relate l’identification d’un
problème. L’analyste a ici pu reconstituer l’enchainement des actions qui ont amené ce
dysfonctionnement et peut donc alors procéder à la recherche d’une solution viable pour
éviter de répéter ce problème dans l’avenir.
La figure suivante montre la caractérisation des critères décrivant un évènement
collaboratif, ici la réunion de travail en présentiel relative à la conception de l’outillage. Cette
réunion n’a pas été planifiée, ni requise par le chef de projet, et les supports habituels des
acteurs ont été utilisés : l’outil de GPAO en l’occurrence. Le commentaire signale qu’à ce
stade du processus de conception, une étude préliminaire aurait due être faite pour définir
une enveloppe financière validée par le client. Cela sous-entend que les solutions possibles
de conception étudiées durant la réunion correspondent à des coûts très hétérogènes,
empêchant ainsi la prise de décision. D’où le besoin de déclencher une réunion avec le
client, comme indiqué dans la figure 20.

Définition besoin

Besoins du client

Une rencontre est planifiée chaque semaine.

Patrick dirige la réunion et répartit les tâches dans l’équipe.

Figure 23. Critères collaboratifs de l’évènement “definition besoin”, projet AGV7

La figure 21 montre l’analyse menée sur l’évènement collaboratif « définition des

besoins », qui a pour but de valider si l’ensemble des besoins identifiés est suffisant pour
engager l’étude correspondante. En premier lieu les indicateurs qualitatifs indiquent que cet
évènement auquel participait le responsable hiérarchique révèle : un bon niveau de

99
Rapport d’habilitation Contributions scientifiques Christophe MERLO

consensus entre les acteurs, une motivation moyenne, une discussion plutôt productive mais
de faible efficacité au niveau collaboratif. Le commentaire précise cette évaluation : comme
les acteurs sont tous en surcharge de travail, aucun n’a pleinement participé pour garantir
que les besoins sont exhaustifs. La figure 22 précise que cet évènement impacte
l’évènement suivant, d’identification et de planification des tâches, ce qui aboutit au manque
d’information sur les couts constaté plus tard dans le processus.

Définition besoin

Sur le vif

Equipe impliquée mais en surcharge de travail, d’où pas de réelle

Participation pour définir de nouvelles tâches techniques

Figure 24. Analyse de l’évènement “definition besoin”, projet AGV7

Le problème ainsi rencontré et les causes ainsi identifiées permettent ensuite à l’analyste
de préconiser différents types de solution. Dans cet exemple il peut se focaliser sur les
aspects humains de la cause et travailler avec le responsable de l’entreprise sur
l’organisation et la composition du département technique et des équipes projet. Mais il peut
aussi se focaliser davantage sur la conduite du projet et établir un processus type plus
détaillé comportant des tâches obligatoires et des tâches conditionnées par différents
critères à évaluer en cours de projet. Enfin il peut aussi se focaliser sur les outils à
disposition du chef de projet et des acteurs en définissant des fiches types pour chaque type
d’évènement collaboratif, fiche comportant des indicateurs ou des actions à évaluer de façon
systématique de façon à pallier le manque d’investissement des acteurs.

La démarche mise en œuvre lors de ces expérimentations a donc été formalisée sous la
forme d’une méthode d’analyse de la collaboration et de préconisation pour la conduite.
Cette méthode (figure 23) s’appuie sur l’outil CoCa et aboutit à des propositions
d’amélioration de la conduite par les chefs de projet.

100
Rapport d’habilitation Contributions scientifiques Christophe MERLO

Trois types principaux de propositions ont pu être déterminés :

− des préconisations portant sur une meilleure prise en compte des facteurs humains
par le chef de projet : organisation des équipes, mise en place de moyens logiciels ou
procéduraux pour la collaboration plus adaptés, etc ;
− des préconisations portant sur une meilleure caractérisation des processus de
conception : des processus formalisés à un niveau de granularité plus fins, pouvant
comporter l’identification de séquences optionnelles ou résultant de décisions
intermédiaires, la définition de règles pour aider à la prise de décision, ou la
caractérisation de formulaires à destination des acteurs, etc ;
− des préconisations portant sur la collaboration elle-même : identification des tâches
qui doivent proposer voire imposer une collaboration, avec quels acteurs, pour quel
but… ; préconisation des types de collaboration les plus adaptés pour chacune de
ces tâches collaboratives (présentiel ou non, avec un support formalisé ou non, avec
une validation finale ou non…) ; etc.

Gestion des
personnes

Capture Analyse de la Modélisation

Préconisations
des données collaboration des processus

Type de
collaboration

Figure 25. Types de préconisations possibles pour améliorer la coordination

Les propositions visant à détailler le processus de conception ont d’ailleurs pu être

étudiées en liaison avec les systèmes PLM qui ont vocation à piloter les processus
élémentaires de conception. Les processus détaillés et flexibilisés [Badke-Schaub &
Stempfle 04] identifiés grâce à l’analyse de la collaboration permettent d’établir des
spécifications destinées à configurer les systèmes PLM. Cet aspect est développé en fin de
la section 1.4.3.

3.3.4. Synthèse : Coordination et collaboration, 2 concepts liés

Dans le cadre de la conduite de la conception, j’ai d’abord mené plusieurs travaux

portant sur la coordination de la conception, ce qui se traduit par des modèles et outils
destinés à venir supporter principalement les chefs de projet. La prise en compte du facteur
humain est indispensable pour ne pas réduire les acteurs de la conception à de simples
ressources qui reçoivent des directives et les exécutent. Ce facteur humain est l’une des
origines amenant à la grande variabilité des processus de conception.
L’étude de la collaboration est donc indispensable pour donner au chef de projet des
outils permettant de réduire cette variabilité pour de la conception routinière, ou au contraire
de l’exploiter au mieux pour de la conception innovante par exemple. Les travaux et les

101
Rapport d’habilitation Contributions scientifiques Christophe MERLO

expérimentations réalisés montrent que coordination et collaboration sont intimement mêlées

et relèvent souvent du niveau de granularité que l’on considère. Une tâche est prévue et
planifiée à un niveau donné, c’est la coordination, mais les actions engagées par les acteurs
pour mener à terme cette tâche peuvent relever de la collaboration. Certaines de ces actions
pouvant correspondre à des ajustements entre les acteurs pour s’organiser, la collaboration
implique aussi des actions de coordination.
Coordination et collaboration sont indissociables et les études menées sur la
collaboration viennent compléter les études prévues pour la mise en œuvre de la conduite,
au sein de la méthodologie GRAI Ingénierie, comme le montre la figure suivante.

Observation Modélisation Formalisation Déploiement

Analyse solutions

Axe
Méthodologie GRAI Ingénierie
Système

Modélisation du système de conception

Modélisation des connaissances
Audits Modélisation du système d’information
Interviews Implantation, Mise en
œuvre de la conduite

Axe
Méthode d’analyse de la collaboration entre acteurs
Hommes

Analyse des Capitalisation des

évènements bonnes pratiques
Observation collaboratifs
participante Réingénierie des processus
Gestion du changement

Figure 26. Cartographie de mes apports scientifiques

102
Rapport d’habilitation Contributions scientifiques Christophe MERLO

3.4. AXE ENVIRONNEMENTS D’ASSISTANCE : LA PROPOSITION DE

SYSTEMES D’INFORMATION POUR LA CONDUITE ET LES ACTEURS

Dans cette section, j’aborde l’axe relatif à l’élaboration d’environnements d’assistance

informatiques. Les différents travaux engagés reposent sur l’exploitation de plusieurs types
de résultats portant sur :
− les approches orientées-objets [Booch et al. 99, Quatrani 00] et les systèmes
d’information collaboratifs [Johansen 98] pour des travaux de spécification d’outils ;
− les systèmes multi-agents [Ferber 97, Jennings et al. 98] pour des travaux faisant
appel à la gestion dynamique et collective des connaissances ;
− et les systèmes PLM [CIMdata, 03, Liu et al., 01] pour l’étude de ces outils.
Les différents prototypes logiciels sur lesquels je suis intervenu ont été conçus pour
répondre à des besoins applicatifs spécifiques Ils ont été à chaque fois l’occasion de mener
une réflexion sur la démarche méthodologique à mettre en œuvre pour garantir la mise au
point d’un environnement logiciel répondant simultanément aux besoins spécifiés par des
travaux scientifiques préalables, mais aussi aux futurs utilisateurs, tout en prévoyant une
intégration potentielle à un environnement industriel.

Contributions : méthode de spécification d’environnements d’assistance pour

la conduite ; méthode de spécification et d’implémentation d’outils PLM

L’une des principales contributions, à ce jour encore inachevée, porte sur la formalisation
d’une méthode générique destinée à spécifier et mettre en œuvre un environnement
d’assistance pour la conduite. Aujourd’hui n’a été formulée que la partie amont : une
méthode de spécifications couplée à la méthodologie GRAI Ingénierie de façon à intégrer les
besoins et modèles métiers issues de la conduite. Elle a été appliquée dans le cadre du
projet IPPOP, mais également lors du développement du logiciel CoCa, du prototype logiciel
impliquant des agents logiciels, et actuellement dans le projet ANR ATLAS.
Cette méthode a également été appliquée pour la spécification d’outils PLM (§) et a été
couplée à la méthode d’analyse des mécanismes collaboratifs pour y intégrer les
améliorations et préconisations issues de l’observation directe des acteurs (thèse de G.Pol,
§). Il s’agit d’une contribution originale qui se veut être une alternative aux approches de type
« pattern » développées par exemple par [Gzara 05]. L’étude des systèmes PLM a permis
notamment de démontrer leurs limites en matière de conduite de la conception, tant au
niveau de la prise de décision et du pilotage du processus de conception, que des besoins
métiers des acteurs de la conception.

Contributions : principe technologique pour l’implémentation de mécanismes

de conduite dans les outils PLM ; modélisation des préférences utilisateurs en
conception collaborative ; intégration du concept ULM dans la gestion du cycle
de vie produit

103
Rapport d’habilitation Contributions scientifiques Christophe MERLO

Suite à ce constat, plusieurs contributions venant compléter la méthode générique de

spécification et de mise en œuvre ont été réalisées :
− la proposition d’un mécanisme basé sur la technologie des workflows pour gérer des
processus multi-niveaux flexibles, en vue d’intégrer les mécanismes de pilotage au
sein des outils PLM ;
− l’intégration de la dimension utilisateur dans les outils méthodologiques et logiciels
des concepteurs par la modélisation de connaissances ‘a priori’ des préférences
utilisateurs (thèse de Livier Serna) ;
− la proposition d’outils de capitalisation des usages du produit pour une exploitation ‘a
posteriori’ par les concepteurs : intégration du concept ULM (Usage Lifecycle
Management), développé par Emilie Chapotot, dans le contexte PLM.

Processus basé sur UML Projet IPPOP

Approches orientées-objet Projet ATLAS

Systèmes d’information collaboratifs Méthode de spécifications Outils CoCa, SIREP

Modélisation des connaissances conceptuelles Prototypes d’agents logiciels
Systèmes multi-agents
Modèle de collaboration
Modélisation d’entreprise et de coordination
Conduite de la conception
Mécanisme de gestion de processus
Méthode de spécifications multi-niveaux flexibles
Systèmes PLM
« Patterns » de processus et d’implémentation d’outils PLM
Maquettes Windchill
Besoins utilisateurs
Modélisation des connaissances
Modélisation des préférences utilisateurs
Concept ULM

Figure 27. Axe « environnements d’assistance », domaines de recherche supports, bilan des
contributions et résultats

3.4.1. Contribution : Méthode pour la spécification conceptuelle

d’environnements d’assistance

Toute démarche de génie logiciel comporte une phase d’analyse puis une phase de
conception avant de procéder au développement proprement dit de l’environnement logiciel.
Mes différentes expériences en développement de produit, que ce soit dans un contexte
scientifique ou dans un contexte d’exploitation pédagogique ou industrielle, m’ont conduit à
la position suivante : le développement d’un environnement logiciel complexe relève de
spécialistes, sur la base de spécifications techniques qu’ils ont eux-mêmes élaborées avant
de démarrer la phase de conception. Car c’est durant cette phase que sont réalisés les choix
des technologies de développement, des outils logiciels et des composants sur lesquels sera
construit le futur environnement logiciel. Dans le cadre de mes activités scientifiques je me
suis donc focalisé sur la phase d’analyse et la production des informations requises pour la
phase de conception et le transfert des connaissances adéquates à destination des
développeurs.
Par considère, je considère les différents modèles résultant d’une approche scientifique
et destinés à être exploités par les spécialistes du développement logiciel comme un
ensemble formant des « spécifications conceptuelles ». Ces spécifications fonctionnelles se

104
Rapport d’habilitation Contributions scientifiques Christophe MERLO

différencient des spécifications techniques de développement en cela qu’elles ne

représentent pas les spécifications établies par les utilisateurs potentiels, mais qu’elles
constituent une réponse générique à une problématique propre à l’organisation des
utilisateurs potentiels. Le travail des spécialistes en développement consiste dans un
premier temps à traiter ces spécifications conceptuelles pour en faire un produit logiciel
opérationnel.
Dans le cadre de ma thèse de doctorat, j’ai élaboré une première méthodologie relative à
la phase d’analyse [A6] conciliant 2 points de vue :
− l’expertise « métier » [Liao 05], qui a permis d’élaborer différents modèles comme par
exemple ceux de la méthode GRAI Ingénierie : les principes de structuration, les flux
d’information, les différentes catégories de connaissances modélisées ; la
modélisation métier formalise les possibilités escomptées du système et des besoins
utilisateur en tant que solution générique issue de la résolution à un niveau
conceptuel d’une problématique donnée,
− la « vue de l’utilisateur », qui permet de définir les besoins opérationnels de
l’application : la nature des interactions entre les utilisateurs, l’impact des facteurs
socio-culturels, l’influence des habitudes quant aux outils existants et l’ergonomie des
interfaces, l’évolution de l’entreprise, de son organisation et donc de ses besoins ; la
modélisation des besoins donne une description de la vision du système, des besoins
fonctionnels et non fonctionnels intégrant les contraintes d’un environnement
industrialisable.
La mise en œuvre de la méthode dans son ensemble s’appuie sur un ensemble de
modèles, représentés par des diagrammes UML (figure 20), qui sont réalisés en respectant
une chronologie précise [Quatrani 00]. Cette analyse se focalise sur la description
fonctionnelle du système d’information de façon à pouvoir décrire globalement ses
fonctionnalités principales vis-à-vis des acteurs. La démarche adoptée, symbolisée par les
flèches de parcours de la figure 26, s’inspire de cette chronologie et se focalise sur les
aspects suivants :
− Etape 1 : caractérisation des fonctions principales du système vues sous l’angle de
l’utilisateur, puis définition du comportement de ces fonctions sous forme d’actions :
diagrammes des cas d’utilisation, puis diagrammes d’activité.
Cette première étape reprend le travail déjà effectué dans le chapitre 3 à l’aide des
formalismes actigrammes et sert à supporter les étapes suivantes. Les diagrammes
d’activités établis pour l’acteur de la conduite et pour l’acteur de la conception viennent
compléter la description du comportement attendu du système pour en formaliser la
dynamique en décrivant les activités résultant de l’interaction des acteurs avec le système et
leurs enchaînements. Ces activités sont ordonnées chronologiquement et précisent les
alternatives ou synchronisations nécessaires.
− Etape 2 : définition de la structure statique du système par l’identification des classes
nécessaires à la réalisation des opérations précédentes, et ébauche des
diagrammes de classes correspondant ; la correspondance entre ces classes et la
modélisation des connaissances effectuée au chapitre précédent est bien entendu
établie,

105
Rapport d’habilitation Contributions scientifiques Christophe MERLO

− Etape 3 : caractérisation de scénarios détaillés à partir des diagrammes de cas

d’utilisation et permettant de les appliquer dans différents contextes,
− Etape 4 : définition de la représentation temporelle des objets (et/ou classes) et de
leurs interactions via l’échange de messages (diagrammes de séquence complétant
les scénarios), les diagrammes de collaboration ne sont pas élaborés dans la mesure
où ils comportent des renseignements proches de ceux fournis par les diagrammes
de séquence, mais avec une vision spatiale plutôt que temporelle,
− Etape 5 : reprise des diagrammes de classes pour établir les relations unissant les
différentes classes ; cette étape conduit à réaliser une seconde itération sur les points
précédents pour compléter les modèles et aboutir à des solutions plus conformes aux
besoins,
− Etape 6 : représentation des aspects dynamiques du système par la réalisation des
diagrammes états-transitions modélisant le comportement d’une classe à partir de
ses états possibles.

Vue métier Modélisation du système d’information

Structure Diagrammes
Diagramme de 6
GRAI R&D des cas
composant
d’utilisation

Diagrammes
Formalisme état - transition
processus Diagrammes Modèles
Modèles
d’activités Modèles 5

2 4
Diagrammes de
séquence
Modèle des
3
connaissances Diagrammes de
pour la conduite classes

Figure 28. Diagrammes UML et démarche proposée illustrée pour la méthode GRAI Ingénierie

La vue de l’utilisateur n’est pas ici exprimée et a été développée à travers différents
travaux : le projet RNTL IPPOP dans un premier temps mais aussi dans le cadre du
développement du logiciel CoCa (thèse de G.Pol), puis plus récemment dans le cadre du
projet ANR ATLAS. Une nouvelle version améliorée de cette méthode de spécification est
ainsi proposée (figure 27).
Le projet IPPOP a montré les limites de la première méthode de spécifications en
démontrant les ambiguïtés pouvant exister dans la collaboration entre des acteurs de
métiers et de cultures différentes. A titre d’illustration les diagrammes de classe produits lors
des étapes 2 et 4 ne formalisent et ne représentent pas les mêmes concepts selon qu’ils
sont émis ou exploités par des scientifiques pour exprimer des solutions génériques, ou des
développeurs professionnels pour spécifier un environnement logiciel opérationnel. C’est
pourquoi j’ai préconisé la séparation de la phase d’analyse en deux sous-phases :

106
Rapport d’habilitation Contributions scientifiques Christophe MERLO

− la première destinée à élaborer une modélisation « conceptuelle » des spécifications,

basée sur l’utilisation de formalismes reconnus par les développeurs, notamment les
formalismes UML ;
− la seconde destinée à élaborer des « spécifications techniques » du futur système
d’information. Cette sous-phase peut être prise en charge par une équipe de
développement ou par une équipe mixte de chercheurs et de développeurs de façon
à garantir un meilleur transfert de connaissances.
En outre, les projets réalisés ont montré l’intérêt de « matérialiser » au plus tôt les
principes, modèles et mécanismes génériques élaborés pour montrer concrètement leur
impact au niveau de l’utilisateur. Cette « vue utilisateur » sera donc basée sur la production
de « maquettes » représentant sous forme de séquences d’écrans des scénarios courts
montrant les interactions entre un utilisateur et le futur système d’information.

Spécifications conceptuelles

Diagrammes 6
des cas Diagramme de
d’utilisation composant
1

Vue métier Diagrammes

Diagrammes
état - transition
d’activités 4
2 5
Diagrammes de
Diagrammes de séquence
classes
Spécifications
3 techniques

Vue utilisateur Scénarios

utilisateurs
Maquette

Figure 29. Diagrammes UML et démarche de spécification conceptuelle

Dans le projet ATLAS, il est prévu que ces scénarios soient coordonnés par un industriel
ayant déjà l’expérience de projets de R&D et construits à partir de collaborations avec des
industriels de type utilisateurs finaux. Les maquettes seront élaborées dans un premier
temps par les laboratoires de recherche puis reprises lors des spécifications techniques
proprement dites. Ces dernières intègrent les contraintes industrielles et notamment les
interactions avec les outils existants : interactions au niveau des acteurs (tâches réalisées
sur des outils existants), des données (échanges entre le futur environnement d’assistance
et des outils existants), ou des fonctions (actions déclenchées depuis l’environnement
d’assistance mais réalisées dans des outils existants).
Cette démarche permet d’intégrer les multiples points de vue qui se confrontent dans un
projet de R&D en vue de répondre de façon générique à une problématique industrielle : les
modèles et concepts scientifiques préconisés, les besoins utilisateurs et ergonomiques tant
au niveau statique (données) qu’au niveau dynamique (fonctionnement), et les contraintes
opérationnelles.
Dans la prochaine section nous allons évoquer les principales contributions élaborées
lors de la production d’environnements logiciels pour la conduite.

107
Rapport d’habilitation Contributions scientifiques Christophe MERLO

3.4.2. Contributions : Des environnements d’assistance pour la conduite

Architecture globale d’un environnement pour la conduite

L’environnement d’assistance préconisé lors de ma thèse de doctorat doit :
− aider les acteurs du système décisionnel à structurer le système technologique par la
décomposition progressive d’un processus en sous-processus destinés à satisfaire à
des objectifs de conception de plus en plus réduits et maîtrisables,
− donner les moyens aux acteurs du système technologique d’atteindre leurs objectifs
en leur fournissant un cadre de travail adéquat et en leur permettant de formaliser
l’ensemble des connaissances produit,
− faciliter l’archivage des connaissances pour les acteurs de la conduite en vue
d’évaluer la performance atteinte, tout en minimisant le travail requis pour assurer cet
archivage,
− permettre aux acteurs de la conduite de formaliser cette évaluation, les écarts
constatés, puis les diagnostics et les problèmes identifiés en vue de prendre des
mesures correctives venant redéfinir les plans de coordination.
Plusieurs éléments sont essentiels pour le choix d’une architecture permettant de
répondre à ces objectifs. Si les modèles proposés précédemment répondent aux besoins
initialement présentés, surtout ceux de la vue métier, il faut garantir un niveau d’adéquation
satisfaisant en se basant sur les besoins exprimés dans les vues utilisateur (ergonomie et
facteurs socio-culturels principalement) et d’implémentation (évolutivité et intégration). Les
différentes classes sont alors regroupées au sein de composants qui proposent une
structuration fonctionnelle de la future architecture logicielle (figure 28) :
− le « moteur GRAI Ingénierie » qui regroupe les classes spécifiques au
fonctionnement du système et assure la coordination de l’ensemble des flux
d’information entre les utilisateurs puis entre les utilisateurs et les autres composants
du système d’information. Nous choisissons la technologie des gestionnaires de
« workflow »1 pour répondre aux besoins de la classe « moteur GRAI Ingénierie » et
faciliter l’identification du contexte des actes et des activités.
− les « bases de connaissances » qui regroupe des classes génériques utilisées pour
gérer les informations archivées.
− l’« exploration des bases de connaissances » qui permet à l’utilisateur d’accéder aux
informations archivées à travers différents filtres.
− la « capitalisation » qui regroupe les classes permettant de générer des
connaissances de capitalisation à long terme soit de façon formelle, soit en
s’appuyant sur des connaissances d’exploitation.

1
Workflow : terme anglo-saxon désignant l’automatisation d’un processus associé à des activités
humaines. Les rares traductions existantes ne donnant pas satisfaction (« flot de travail » pour [Ben
Attalah 97] ou « flux de travail » pour [Kanawati 97]) nous continuons à utiliser ce terme.

108
Rapport d’habilitation Contributions scientifiques Christophe MERLO

− les « coordination, suivi et diagnostic » qui permet de manipuler ce type de

connaissances.
− le « produit » qui permet de manipuler les connaissances produit.
− le « processus » qui permet de manipuler les connaissances processus (traçabilité)
en liaison avec la gestion des tâches assurée par le composant « moteur GRAI
Ingénierie ».
Coordination, suivi et
diagnostic

Moteur GRAI
Ingénierie

Réalisation du plan de Coordination

Révision du plan de coordination

Produit Définition des Indicateurs Base de

connaissances
Définition écarts - diagnostic

Saisie des Connaissances Produit

Exploration des bases de
connaissances

Processus

Capitalisation
Définition d'un cas à retrouver

Exploration des Bases de

Identifier les activités du processus Connaissances

Définition d'un cas pour capitalisation

Figure 30. Diagramme des composants

Cette architecture générique doit être complétée par la description d’une interface
utilisateur afin de caractériser la mise en œuvre des concepts issus de la recherche. L’IHM
doit constituer un relais efficace pour les fonctionnalités pressenties et faciliter l’accès aux
informations adéquates, la figure 29 en propose une description macroscopique s’appuyant
sur l’architecture proposée.
Ces travaux génériques ont été exploités ensuite dans différents travaux et projets pour
aboutir à des implémentations partielles et complémentaires destinées à des utilisateurs
spécifiques : PEGASE pour une vocation scientifique, IPPOP pour traduire les points de vue
de EADS CCR et de Alstom Moteurs, ATLAS pour les industriels du pole AESE.

109
Rapport d’habilitation Contributions scientifiques Christophe MERLO

LISTE DES Liste de tâches Cadre de décision : Objectifs Espace de collaboration

TACHES
Urgent 1
PRODUIT
Session: Mikel

Produit Urgent 2
A faire 3
A faire 4
Informations Avancement du plan de coordination
de suivi

CAO
Plan de
coordination
, objectifs,
processus Messages: Oihana

Analyse
& Messages: Xabi
Diagnostic

Recherche
Logiciel CAO Logiciel métier Capitalisation Forums Messagerie
d’infos

Figure 31. Exemple d’une interface graphique pour un acteur d’un centre de décision

Figure 32. Exemple d’IHM du prototype IPPOP : création de tâche

Dans le cadre du projet IPPOP, les travaux menés ont permis de compléter les modèles
pour la conduite de la conception, désignée comme la dimension organisation, en intégrant
deux dimensions supplémentaires : la dimension produit, synthèse des travaux réalisés par
plusieurs laboratoires français sur la modélisation multi-vues du produit ; et la dimension

110
Rapport d’habilitation Contributions scientifiques Christophe MERLO

processus, qui associée à la modélisation du produit, assure la traçabilité au sein du

système technologique. Ces deux dimensions sont intégrées dans notre architecture au
niveau des composants produit et processus. En outre dans IPPOP sont prises en compte
des contraintes industrielles : l’environnement d’assistance doit être couplé aux outils CAO et
aux outils SGDT de l’entreprise pour la modélisation du produit et la gestion des informations
relatives à la gestion du cycle de vie du produit. Enfin, les différents composants proposés et
illustrés par la figure 28 ont été regroupés au sein d’une nouvelle d’IHM (figure 30) pour ne
faire apparaitre que 3 composants principaux, ce qui contribue à simplifier l’IHM initiale.
Dans le cadre des développements réalisés par [Robin 2005] pour le prototype PEGASE,
ces principes ont été appliqués mais en se focalisant uniquement sur les composants
processus, coordination et moteur GRAI ingénierie.
Le projet ATLAS [Aldanondo et al. 08] se focalise quant à lui sur les dimensions produits
et processus : éviter que la conception ne débouche sur des infaisabilités de planification ou
pouvoir prendre en compte des contraintes de projet dès les premiers choix de conception
sont les buts principaux de ce projet. Pour ce faire, les choix de conception et de planification
considèrent des ensembles d’alternatives, de variantes et/ou d’options assimilables à de la
connaissance de conception et de planification. Ces degrés de liberté sont progressivement
réduits pour aboutir à la définition finale du produit et de son projet de réalisation. Le
prototype logiciel ATLAS va en conséquence associer un environnement de conception avec
un environnement de gestion de projet. Les connaissances caractérisant les
interdépendances entre les deux environnements permettront alors de propager les
décisions ou choix d’un environnement vers l’autre. La dimension organisation n’est pas
omise puisqu’elle permet d’intégrer les 2 dimensions couplées produit-processus au sein
d’un environnement orienté vers la gestion de projet, en reprenant les travaux menés au sein
d’IPPOP. La figure suivante illustre l’une des premières IHM spécifiant le cadre général du
prototype.

Atlas - Conduite de projet PLANIFICATION PRODUIT

PROJET Cadres Ressources Sous-Projets Planification Suivi

Projet actif

Mes projets + Créer nouveau

Responsable
Référence Nom Description Responsable Projet père Début Lancé Fin
hiérarchique
AXZ56 BATEAU Projet support d’ATLAS Michel Aldanondo - - 01/09/08 05/09/08 01/12/08 sélectionner - lancer

1 projet(s)

Mes tâches à réaliser + Créer nouvelle

Référence Nom Description Responsable Projet associé Début Fin

1 Tdf3
tâche(s) Structurer projet Tâche automatique après création projet Michel Aldanondo BATEAU 01/09/08 10/09/08 consulter - terminer

Mes messages
Message(s) d’alerte d’alerte + Créer nouveau

Des modifications ont été apportées au projet BATEAU marquer lu

1 message(s)

Figure 33. IHM initiale du prototype ATLAS : page récapitulative des projets / tâches

111
Rapport d’habilitation Contributions scientifiques Christophe MERLO

La réalisation puis l’expérimentation de ces prototypes (IPPOP auprès d’EADS CCR et

d’Alstom Moteurs et Pégase auprès les étudiants ESTIA en option CGP) ont montré les
limitations des IHM pour l’instant développées et de nouveaux travaux doivent être mis en
œuvre pour les améliorer. Toutefois ces premiers tests concluent au fait que les principales
fonctionnalités existantes permettent de répondre aux besoins suivants :
− corréler l’organisation de l’entreprise et la structuration du projet,
− structurer le projet et planifier le processus de conception en intégrant des indicateurs
de performance de type processus mais aussi organisation et produit,
− assurer le suivi du projet en s’appuyant sur cette intégration et ces indicateurs.
Ces retours mettent aussi en évidence certains mécanismes complexes pour lesquels les
choix pour le futur développement influencent fortement la performance du service attendu
par les utilisateurs, et notamment :
1. l’identification et la structuration des activités constituent des tâches fastidieuses pour
les acteurs dont ils n’ont pas de retour immédiat susceptible de les motiver ; aussi
est-il nécessaire d’automatiser la saisie des activités élémentaires, et de les
contextualiser pour limiter au maximum la partie saisie et validation finale qui doit
rester sous la responsabilité humaine,
2. le problème de la contextualisation des activités, introduit par le point précédent, qui
se pose pour l’utilisateur recevant une tâche à réaliser : pour un message ou une
activité reçue, il doit pouvoir savoir à tout moment quelle est son origine (quel acteur
et quel centre), à quel plan de coordination peut-on les rattacher, de quel cadre de
décision de niveau supérieur ils dépendent et quels sont les autres acteurs impliqués
dans la même séquence d’activités. La résolution de ce problème est liée aussi bien
à un problème d’organisation qu’au choix d’une technologie,
3. la formalisation et la validation d’un plan de coordination puis des écarts/diagnostics
sont réalisées collectivement, aussi faut-il prévoir les mécanismes de coordination
adéquats,
4. la manipulation du modèle de produit et la validation des modifications dépendent
également de multiples acteurs,
5. la multiplication des messages à destination d’un même acteur que notre système
d’information implique : les acteurs utilisant des SGDT sont habitués à la réception de
tâches à effectuer, toutefois notre système prévoit également des messages pour
valider les modifications des connaissances produit, pour contribuer à l’élaboration du
plan de coordination, pour saisir ou exploiter des informations de suivi. Il faut là
encore trouver des solutions pour faciliter la gestion de ces messages.
L’architecture proposée n’est pas suffisante pour décrire comment y répondre. J’ai
préconisé plusieurs choix technologiques avec pour objectif principal de répondre à ces
interrogations, de façon à proposer un système d’information qui réponde aux besoins métier
mais aussi aux besoins d’efficacité que requièrent les utilisateurs pour une exploitation en
milieu industriel. J’ai ainsi préconisé que les points 1 et 2 soient traités à l’aide des
technologies de workflow et de fonctionnalités de type gestion de tâches par workflow telles
qu’elles sont mises en œuvre au sein des environnements PLM. J’y reviendrai dans la

112
Rapport d’habilitation Contributions scientifiques Christophe MERLO

section suivante. Quant aux autres points, ils sont représentatifs d’un système d’information
qui présente des caractéristiques de pro-activité et qui devient dès lors un véritable
environnement d’assistance. J’ai introduit dans mes travaux le concept d’agent logiciel afin
de les traiter.

Apport des agents

Je considère le concept d’agent logiciel comme un moyen d’améliorer les problèmes liés
à l’identification des actes et à la collaboration des acteurs au sein d’un système
d’information complexe, comme c’est le cas de l’environnement logiciel destiné à la conduite
de la conception. Ces travaux ont été menés très tôt (DEA puis thèse de doctorat) mais
peuvent être considérés comme des travaux réalisés avant l’heure car les problèmes qui ont
été étudiés alors sont des problèmes qui n’ont pas été résolus de façon satisfaisante dans
les travaux et projets ultérieurs, et ils restent d’actualité aujourd’hui, et une piste à
approfondir pour l’avenir.
Les agents [Wooldridge & Jennings 95], [Jennings et al. 98] sont caractérisés par des
capacités de communication [Sreeram & Chawdhry 97], de négociation et de coopération
[Rich & Sidner 97], de réaction ou de définition de leur propre stratégie, et enfin de
capitalisation qui peuvent s’adapter aux besoins de coordination, de collaboration, de
contrôle et de flexibilité du système d’information envisagé. Leur autonomie et leurs facultés
de coopération [Disson et al. 99] sont des caractéristiques utiles pour aider les acteurs à
gérer les connaissances de conception. Dans le cadre de la conception collaborative, des
exemples ont été mis au point pour l’intégration des processus de conception [Petrie et al.
99], pour supporter l’ingénierie simultanée [Prasad 96] [Han et al. 00] ou pour améliorer la
coordination de la gestion des connaissances [Wu 01].
L’environnement d’assistance que j’ai proposé est un système d’information distribué qui
doit être pro-actif. Il est capable de s’appuyer sur les technologies actuellement employées
pour ce type de systèmes : workflow, bases de connaissances, outils de collaboration, IHM
basée sur Internet, … Les composants logiciels traditionnels qui le composent vont interagir
avec des composants logiciels autonomes, les agents, pour améliorer la collaboration et
assister au mieux les utilisateurs. Vus tantôt comme des applications, tantôt comme des
acteurs par les utilisateurs et par les composants classiques, ces agents transforment le
système d’information en un environnement pro-actif capable d’un soutien plus efficace
auprès des utilisateurs.
Ainsi les acteurs agissent dans le système de conception dans un contexte de
coordination et de collaboration à plusieurs niveaux. En particulier :
− ils œuvrent ensemble au sein des centres de conception comme au sein des centres
de décision d’un même niveau décisionnel,
− les acteurs de la conception exploitent simultanément des informations produit
parfois identiques, parfois complémentaires. De ce fait les modifications que chacun
réalise influencent le travail des autres acteurs et doivent rester cohérentes,
− les acteurs de la conduite exploitent les informations de suivi pour réorienter les
activités des centres de conception ou de centres de décision de niveau inférieur.

113
Rapport d’habilitation Contributions scientifiques Christophe MERLO

De ce fait j’ai proposé dans [A1] un ensemble d’agents logiciels venant compléter
l’architecture logicielle de l’environnement d’assistance pour la conduite. Comme le montre
la figure 32, pour un acteur d’un centre de décision donné, l’IHM de l’environnement
d’assistance met à sa disposition un certain nombre de fonctionnalités bien spécifiques.
Chacune gère les interactions avec l’un des composants identifiés, et peut être utilisé par un
agent pour communiquer avec l’acteur.
Bases de
connaissances

Moteur GRAI Exploration des bases de Coordination, suivi et Processus

Ingénierie connaissances diagnostic

Agents Agents
exploration processus
Réalisation du plan
de Coordination
Agents Définition des
Exploration des Bases de Identifier les activités
Connaissances capitalisation Indicateurs du processus
Révision du plan
Agent de coordination Définition d'un
diagnostic
communication Définition d'un
cas à retrouver

Mettre à jour la liste de tâches

Suivi et
Tâches Objectifs Consultation Coordination Traçabilité
écarts

Acteur de la conduite

Figure 34. Interactions entre l’environnement d’assistance et un acteur de la décision

L’agent communication interagit avec l’espace des tâches pour filtrer et gérer alarmes et
messages. Les agents produit et processus utilisent le moteur GRAI Ingénierie pour envoyer
leurs requêtes de validation, de contrôle ou de saisie.
Les agents exploration et capitalisation sont accessibles à travers l’interface spécifique
du composant « exploration des bases de connaissance » pour effectuer des recherches
spécialisées dans les connaissances capitalisées, susceptibles de durer longtemps.
L’espace de consultation contient des outils de visualisation mais est aussi l’espace
employé par les différents agents qui mettent à disposition des informations pour l’acteur :
l’agent communication (messages), les agents exploration ou capitalisation (données
extraites des bases de connaissances).

114
Rapport d’habilitation Contributions scientifiques Christophe MERLO

Les agents produit (pour un acteur de la conception) et processus disposent quant à eux
d’espaces spécifiques pour la visualisation des informations qu’ils manipulent. Les agents
produit sont destinés à gérer la cohérence des informations relatives à la modélisation du
produit lors de modifications en simultané par plusieurs acteurs. Les agents processus
assurent un pré-enregistrement des activités des concepteurs en vue d’assurer la traçabilité
du processus de conception.
D’une façon générale les agents dialoguent entre eux en utilisant des protocoles qui leur
sont propres mais peuvent communiquer avec les acteurs ou avec les composants
classiques à l’aide de protocoles standard (messagerie électronique, communication point à
point par exemple).
Ma contribution relative aux agents comporte plusieurs modèles successifs auxquels on
pourra se référer dans [F36]. A partir de la définition donnée par [Ferber 97]. J’ai d’abord
développé un modèle mathématique destiné à décrire le système multi-agent ciblé et à
caractériser chaque agent, ses actions et ses interactions, comme on peut le voir dans
l’article présenté en annexe. J’en ai déduit une modélisation graphique puis des
spécifications détaillées. J’ai ensuite supervisé la réalisation d’un prototype logiciel de l’agent
produit, qui a pu être testé et validé. Pour le détail de ces expérimentations on pourra se
reporter à [C18], la figure 33 illustre ces travaux en montrant l’interface utilisateur permettant
à un concepteur d’interagir avec les agents logiciels pour valider les modifications apporter à
la modélisation du produit, en cohérence avec les modifications apportées par d’autres
utilisateurs. Cette expérimentation valide la faisabilité d’un environnement d’assistance mixte
basé en partie sur un système d’information traditionnel, interconnecté avec les outils de
l’entreprise et un système multi-agent venant rendre pro-actif ce système d’information.

Messages de confirmation
des agents produits
concernés par les
modifications analysées par
l’agent ApDurand

Figure 35. Interactions entre un concepteur et l’agent produit associé

115
Rapport d’habilitation Contributions scientifiques Christophe MERLO

3.4.3. Contributions : Des environnements d’assistance pour le PLM

J’ai démontré dans mes travaux précédents que l’environnement d’assistance pour la
conduite est destiné aussi bien aux acteurs de la conduite qu’aux concepteurs, et que par
ailleurs il doit être intégré avec les outils de l’entreprise, à savoir les Systèmes de type PLM.
Ces travaux entrent donc plus largement dans un contexte de gestion globale du cycle
de vie du produit (PLM) et impactent la conduite de la conception. Mes premiers travaux en
ce sens ont porté sur l’étude des systèmes SGDT (ou PDM) et PLM existants de façon à
évaluer le niveau de recouvrement de leurs fonctionnalités avec celles préconisées dans
l’environnement d’assistance à la conduite, et ainsi pour déterminer quel type d’intégration
doit être défini entre ces deux types de systèmes d’information. Ces études ont porté aussi
bien sur la manipulation d’informations fortement formalisées que sur la gestion de l’informel.
Ce sera l’objet de ma première section.
Il est apparu progressivement que les systèmes SGDT sont très spécialisés et dans un
contexte PLM plus général il est nécessaire d’étendre leurs fonctionnalités soit directement
soit via de nouveaux outils interopérables. La prise en compte des besoins des futurs
utilisateurs et des contraintes industrielles est un élément essentiel dans la méthodologie de
développement d’environnements d’assistance. J’ai donc été amené à m’intéresser à des
outils destinés aux concepteurs pour prendre en compte le point de vue utilisateur :
− intégrer la dimension utilisateur dans les outils méthodologiques et logiciels des
concepteurs par la modélisation de connaissances ‘a priori’ : c’est le cas des travaux
réalisés à travers la thèse de Livier Serna ;
− proposer des outils de capitalisation des connaissances à destination des utilisateurs
pour une exploitation ‘a posteriori’ des retours d’utilisation par les concepteurs : c’est
par exemple le concept ULM (Usage Lifecycle Management) développé par Emilie
Chapotot dans sa thèse (encadrée par mon collègue à l’ESTIA J.Legardeur) à
laquelle je contribue ponctuellement).
Ces deux points sont abordés dans une seconde puis une troisième section.

Le PLM est une approche stratégique visant à gérer les informations relatives au produit
tout au long de son cycle de vie (figure 34), pour chacune de ses phases, et cela à
destination de tout membre d’une organisation à un niveau technique ou managérial, et de
tout fournisseur, client ou partenaire [Sudarsan 05] clef. Ils supportent les acteurs impliqués
dans le développement de produit en fournissant une plateforme homogène centrée sur le
partage des informations produit. Ils proposent des mécanismes de modélisation structurelle
du produit et de gestion des différentes informations attachées sous forme de document.
Ces outils ont récemment intégré des composants collaboratifs ou orientés projet [CIMdata,
03] et offrent aujourd’hui des fonctionnalités permettant aux utilisateurs de les configurer à
différents niveaux : cycles de vie, workflows [Liu et al., 01], types d’objets entrant dans la
structuration du produit, intégration avec des outils transverses dans l’entreprise [Wang et
al., 02]. Les systèmes PLM actuels intègrent les technologies liées à Internet et offrent des
fonctionnalités similaires aux collecticiels [Johansen 98], [Eynard et al. 02] pour favoriser la
collaboration entre les acteurs.

116
Rapport d’habilitation Contributions scientifiques Christophe MERLO

Ces considérations visent à améliorer de façon significative la réduction des délais de

mise sur le marché de nouveaux produits, tout en améliorant la qualité des produits et la
réduction des couts, la traçabilité des flux d’information et l’automatisation des processus
métiers. A chaque phase du cycle de vie, ils aident les responsables dans leurs prises de
décision grâce à la mise en cohérence de l’ensemble du patrimoine informationnel du produit
[Saaksvuori 04]. Les systèmes PLM sont devenus un noyau fédérateur pour un ensemble
d’outils : CFAO bien entendu mais aussi les systèmes ERP (Enterprise Resource Planning)
et CRM (Customer Relationship Management) par exemple.
Flux d'informations

Méthodes
LE SYSTEME DE Planification
CONCEPTION le produit défini
le produit industrialisé Achats
Etudes
Fabrication
le produit spécifié
Assemblage
Recherche marketing le produit réalisé

le besoin Vente
SYSTEME DE
Maintenance PRODUCTION
le produit livré
Flux de matières
Le marché - L‘utilisation
Le recyclage

Figure 36. Cycle de vie du produit

Etude des capacités des outils SGDT à assurer la conduite

Dans le cadre du projet IPPOP, j’ai pu démontrer que les outils SGDT ne prenaient pas
en compte les apports visés par le prototype IPPOP :
− pour la dimension produit : les outils SGDT ne gèrent que les vues structurelles, via
la gestion de la configuration du produit, et géométriques, via l’intégration avec les
outils CAO, du produit ;
− pour la dimension processus : ces outils SGDT ne gèrent que les processus
préalablement définis grâce aux technologies de workflows, et généralement seuls
les processus de bas niveau, répétitifs et peu variables sont modélisés et pilotés,
comme par exemple le processus de validation d’un document ou le mécanisme de
jalonnement visant à basculer d’un état du produit à l’état suivant dans son cycle de
vie ;
− pour la dimension organisation : les SGDT ne prennent pas en compte cette
dimension si ce n’est à travers l’émergence de quelques fonctionnalités de gestion de
tâches sous forme de planning partagé.
La comparaison entre les SGDT et le prototype IPPOP a toutefois permis de mettre en
évidence que les limitations sur les dimensions produit et processus sont des limitations
métiers liées aux objectifs que se sont fixés les éditeurs vis-à-vis des utilisateurs, et ne sont
pas imposées par les technologies de développement mises en œuvre :
− pour la dimension produit : il est possible d’adapter les bases de données
descriptives de la configuration du produit pour procéder à la modélisation de

117
Rapport d’habilitation Contributions scientifiques Christophe MERLO

d’éléments fonctionnels, d’éléments d’interfaces et d’éléments structurels

(encadrement L.Girouard, §2.2.2, [A4]) tels que prévus dans le modèle PPO ;
− pour la dimension processus : il est possible d’utiliser les technologies de workflow
pour gérer des processus dynamiques (thèse G.Pol, [C44]) et multi-niveaux afin de
pouvoir gérer le processus de conception à chaque niveau organisationnel, lui-même
correspondant aux niveaux de décomposition structurels du projet.
La modélisation multi-vues du produit a été expérimentée avec Windchill PDMLink
(PTC). La figure 35 présente un exemple de structure produit issue d’un mixer : la
décomposition du produit ou de l’assemblage est visualisée et montre les 3 types d’éléments
(C pour Composant, F pour Fonction et I pour Interface) après création de sous-types
différenciés de la classe « Article de référence » présente dans la base de données. Ainsi la
décomposition du produit selon les points de vue structurels, fonctionnels et interface sont
assurés via cette représentation arborescente. Toutefois cette représentation du produit
correspond à une structure de type graphe dans le modèle PPO, elle n’est donc
qu’incomplètement représentée dans le SGDT où seule la structure de type arbre est
utilisable. Les boucles susceptibles d’apparaître dans un arbre génèrent ici des
décompositions infinies et/ou des doublons, comme ici avec la fonction « Serrer crémaillère
sur colonne ».

Figure 37. Arborescence produit multi-vues après personnalisation de Windchill

Les outils PLM ont récemment intégré des fonctionnalités de gestion de projet basées
principalement sur la gestion de tâches et de jalons. Bien qu’il soit possible de gérer des
dates de fin et une planification de tâches et sous-tâches dynamiquement, leurs fortes
limitations [Pol G. et al. 05] limitent l’intérêt de ces fonctionnalités, en particulier pour la

118
Rapport d’habilitation Contributions scientifiques Christophe MERLO

conduite de la conception. Par exemple il est impossible d’instancier des processus

prédéfinis. Par ailleurs les workflow associés aux documents et destinés à gérer les
évolutions de ces documents ne peuvent pas être pilotés depuis la planification établie en
gestion de projet. De ce fait il est impossible d’interconnecter une planification macro
orientée tâches, avec une planification prédéterminée orientée document. Cette limitation
relève de façon claire de la façon dont ces fonctionnalités ont été implémentées, alors que la
technologie de workflow autorise dans l’absolu de tels mécanismes de synchronisation,
même si cette technologie des workflow est généralement mise en œuvre sur des processus
prédéfinis.
Toutefois les études menées sur les outils SGDT et Windchill (PTC) en particulier ont
montré que l’on peut flexibiliser un processus en insérant des « tâches dynamiques », c’est-
à-dire des nœuds où il est possible de demander à l’utilisateur de créer dynamiquement de
nouvelles tâches : ces nouvelles tâches seront gérées comme un sous-processus qui doit
être entièrement réalisé pour que le processus principal puisse se poursuivre. L’objectif
devient alors la mise en place d’un mécanisme de planification pour un responsable en
charge de la conduite d’une équipe.
L’approche GRAI Ingénierie a montré l’effet récursif de la décomposition de projets en
sous-projets, et donc du processus de conception en sous-processus conformément à cette
décomposition. J’ai donc préconisé l’utilisation de mécanismes de lancements de sous-
processus pour permettre de gérer le processus de conception sous la forme de workflow
multi-niveaux, puis d’utiliser des mécanismes de synchronisation pour assurer un pilotage
ascendant et global des processus.
De tels mécanismes existent pour le pilotage de processus de gestion des modifications
de produit, comme le montre la figure 36. Ce processus est composé de 4 phases distinctes,
chacune pilotée par un workflow spécifique :
1. La définition de « rapports de problèmes » par les acteurs de l’entreprise, leur
validation par un responsable local et enfin leur transmission à un responsable
habilité.
2. La caractérisation de « demandes de modification » par le responsable habilité et leur
suivi jusqu’à leur traitement complet. Ce processus déclenche un sous-processus,
celui du traitement de la modification, et comporte des tâches de synchronisation
permettant de déclencher des tâches de vérification quand le traitement sera achevé.
3. La réalisation du traitement par le processus de « gestion de la modification ». Ce
processus type comporte des séquences de tâches déterminant des étapes
d’analyse, de solutions, de définition du nouveau produit et de validation technique.
Chacune utilise une technique de génération de tâches dynamiques autorisant
l’utilisateur à générer lors de l’exécution une nouvelle séquence de tâche et de les
affecter aux personnes de son choix.
4. Par ce biais il est possible de caractériser des sous-processus adaptés au contexte
via des « activités spécifiques » non prédéfinies. Le processus de gestion de
modification s’interrompt jusqu’à la réalisation complète de cette séquence d’activités
spécifiques.

119
Rapport d’habilitation Contributions scientifiques Christophe MERLO

Rapports de Demande de Gestion de la Activités

problèmes modification modification spécifiques

1 workflow
n workflow initiateur 1 workflow
pilote
n activités
pilotées

Figure 38. Mécanisme de gestion de processus multi-niveaux flexibles

Compte-tenu de la flexibilité du processus de conception [Weber et al. 02], notamment

au sein des PME ou au sein des projets innovants, les mécanismes de workflow
implémentés en standard dans les outils PLM ([Gzara 05 ]) vont à l’encontre des besoins des
acteurs qui travaillent quotidiennement par « ajustement mutuel » [Mintzberg 90]. Les
processus coopératifs sont faiblement structurés et les échanges entre acteurs souvent
informels [Baumberger et al. 03], ce qui les amène à gérer des informations non-structurées
ou structurées de façon partielle. Les mécanismes précédents ont été généralisés
(publication [B1]) pour permettre d’une part de gérer les informations semi-structurées via
des documents et des objets spécifiques, et d’autre part de gérer les échanges entre les
acteurs via des processus et des fonctionnalités collaboratives adéquates. La conduite de la
conception à travers les outils PLM doit être étudiée en intégrant dans un environnement
commun la gestion des processus orientés documents et la gestion des processus projets
[Saikali 01].
Dans un contexte PLM, les outils SGDT seuls ne permettent donc pas d’assurer la
conduite de la conception mais doivent être complétés par des outils complémentaires, soit
directement pour supporter la conduite, soit en proposant des outils supports aux acteurs de
la conception. Dans le premier cas la problématique de l’intégration entre un SGDT et un
environnement pour la conduite tel que le prototype IPPOP est identifiée. Dans le second
cas il s’agit d’une problématique de conception d’outils experts. La section suivante illustre
ce principe en présentant les principaux résultats de la thèse de Livier Serna, qui sont une
réponse à la prise en compte des besoins utilisateurs ‘a priori’ par les différents experts, en
vue d’une conception collaborative.

120
Rapport d’habilitation Contributions scientifiques Christophe MERLO

Prise en compte des préférences utilisateurs pour la conception collaborative

La prise en compte des besoins des utilisateurs est fondamentale en conception. Des
méthodologies spécifiques sont mises au point pour enrichir les démarches traditionnelles
des concepteurs. Ce sont par exemple des approches centrées utilisateurs [Veyrat 08],
[Quaranta 94], destinées à intégrer des concepts tels que le confort, l’utilisabilité et l’aspect
esthétique [Sagot 98]. Ces approches sont parfois dénoncées comme étant limitées
[Branguier 04], [Valette 05]. En effet elles ne permettent de prendre en compte qu’une partie
des besoins : ceux exprimés suivant des critères partiels par les utilisateurs finaux.
Dans le cadre de la thèse de L.Serna, portant sur la définition d’une méthodologie de
formalisation des préférences et de choix de solutions, l’un des objectifs consistait à étendre
le champ des critères possibles en s’appuyant sur le concept de préférences et à permettre
une évaluation de ceux-ci, et donc des choix de solutions possibles, indépendamment de la
nature de ces préférences. Le second objectif vise la production d’un environnement
d’assistance dans un contexte PLM, en y étudiant comment intégrer les futurs utilisateurs.
Pour y répondre, la modélisation des préférences et la définition d’outils pour l’exploration
virtuelle des espaces de recherche seules ne suffisent pas. Il faut étudier l’aspect
méthodologique afin de permettre aux acteurs d’appliquer ces modèles puis d’en évaluer
l’impact sur le processus de conception collaboratif une fois mise en œuvre. Dans [A14], est
présentée une méthodologie permettant de rendre à la fois plus objectifs et plus consensuels
certains choix de conception, jugés déterminants, tout en facilitant la recherche de solution
en restreignant l’espace de recherche. Elle comporte trois phases : la négociation qui
structure l’espace de solutions en sous-ensembles à partir d’indicateurs de négociation ; le
choix qui ordonne ces sous-ensembles à partir d’indicateurs de choix ; et la décision qui
identifie les régions où les solutions sont optimales, à l’aide d’indicateurs de décision.
De cette méthodologie sont déduites les spécifications d’un environnement d’assistance
venant supporter les mécanismes de collaboration au sein d’un collège d’experts
multiculturels, considérés comme autant d’utilisateurs, en vue de pouvoir effectuer des choix
globaux et cohérents. Le groupe projet considéré est chargé d’évaluer l’utilité de chaque
indicateur de choix issu de l’étape précédente pour évaluer les solutions de conception pour
les principales situations de vie du produit. Une matrice de décision permet de collecter les
avis de manière homogène. Un traitement statistique inspiré de [Taguchi 86] est opéré sur
les valeurs de cette matrice, dont sont éventuellement exclus les indicateurs de choix non
significatifs. Il en émerge une classification des indicateurs (prioritaires ou potentiellement
nuisibles dans le processus de décision) mais aussi des couplages entre indicateurs (en
phase ou en opposition).

Ces travaux, complémentaires à ceux menés sur la modélisation multi-vues dans les
outils PLM du point de vue de la modélisation du produit, permettent d’étendre la notion
d’utilisateurs du produit des utilisateurs finaux aux concepteurs eux-mêmes, tout en
proposant un environnement d’assistance support. Ils constituent un focus particulier de
l’approche GRAI en conception puisque ces travaux visent à gérer les connaissances des
concepteurs correspondant à la prise en compte des besoins utilisateurs (nous sommes
dans le « plan objet » de la grille GRAI R&D, évoqué dans le §1.2.1). Ils mettent en évidence
un besoin de coordination nécessaire, puisque différents experts participent chacun dans

121
Rapport d’habilitation Contributions scientifiques Christophe MERLO

leur domaine à l’élaboration des préférences, afin de garantir l’homogénéité de l’ensemble

des modèles et de participer à la recherche de solutions satisfaisantes.
Toutefois dans une approche PLM il est nécessaire de considérer l’ensemble des phases
constituant le cycle de vie du produit, en particulier les phases de production et de
maintenance. La section suivante aborde la problématique de la prise en compte des
utilisateurs selon un point de vue différent, celui de l’analyse ‘a posteriori’ des retours
effectués par des experts ou des utilisateurs ‘a posteriori’, pour une exploitation plus orientée
amélioration / modification de produits.

Gestion du cycle de vie des usages du produit

L’objet des travaux en voie d’achèvement avec E.Chapotot portent sur la prise en compte
par les concepteurs des besoins exprimés par l’ensemble des acteurs intervenant tout au
long du cycle de vie du produit, en particulier la production et la maintenance du fait que
l’entreprise support de ce travail s’est focalisée sur ces activités pour ces produits : des
turbines pour l’aéronautique.
En dépit du fait qu’aujourd’hui les systèmes d’information mis en œuvre dans un contexte
PLM permettent de couvrir de nombreux besoins pour la gestion des données relatives au
produit, il est très difficile de collecter et de réutiliser des informations pertinentes en
provenance des utilisateurs finaux et des opérateurs de maintenance, quand le produit est
dans ses phases d’exploitation. Ce phénomène est amplifié dans les grandes compagnies
internationales dans la mesure où les départements au contact de la clientèle restent
éloignés de ces utilisateurs et opérateurs, eux-mêmes extrêmement disséminés de par le
monde. Les flux d’information multiples, quand ils existent, alimentent des bases de données
hétérogènes résultant d’initiatives locales. Il en résulte d’importantes difficultés pour
superviser ces flux interconnectés d’information et obtenir une vision globale des usages qui
sont faits des produits présents sur le marché. Toutefois, dans une approche PLM, il est
crucial pour le processus de conception d’avoir un retour fiable sur les usages en vue de
concevoir de nouveaux produits plus adaptés et porteurs d’innovation.
C’est pourquoi nous avons choisi de nous focaliser sur les phases d’exploitation, durant
lesquelles le produit est utilisé à la fois par les utilisateurs finaux et par un ensemble
d’opérateurs qui participent à sa maintenance, aux réparations et autres actions visant à
prolonger son utilisation directe. Dans le cadre de la thèse d’Emilie Chapotot, Turbomeca
(groupe Safran) est confrontée à cette problématique : son département de maintenance a
besoin de collecter ces informations sur l’usage pour des raisons de traçabilité et de
fourniture de prestations de service à haute valeur ajoutée à ses clients. Les opérations de
maintenance étant réalisées conjointement par des tiers répartis dans le monde entier, il est
essentiel de maitriser ces retours d’information sur les usages pour pouvoir les exploiter
dans le cadre de la maintenance prédictive puis de la conception de nouvelles turbines.
Une approche globale dédiée au management du cycle de vie des usages d’un produit a
été proposée pour assurer ce retour d’information et garantir sa réutilisation : cette approche
est dénommée approche ULM (Usage Lifecycle Management). Elle comporte un ensemble
de méthodes et d’outils qui permettent de faire un retour en conception des informations
capitalisées sur l’usage des produits pour permettre la genèse de solutions innovantes en
phases amont. En proposant une solution à la problématique de coordination de la

122
Rapport d’habilitation Contributions scientifiques Christophe MERLO

connaissance produit et en faisant le lien avec la conception et les besoins utilisateurs, cette
approche participe à la conduite de la conception, telle qu’évoquée au §1.2.1, figure 11.
L’approche ainsi mise au point repose sur une capitalisation « semi-automatique »des
informations sur l’usage via la mise en œuvre du triptyque Produit / Utilisateur /
Environnement. La carte des connaissances de la figure 37 montre différents concepts
associés à ce triptyque et permet de caractériser différents types d’usage qui aboutissent à
la définition d’une ontologie sur l’usage. Cette ontologie est exploitée pour faciliter
l’identification, la classification et la formalisation des usages, du type de produit et du
contexte d’utilisation en fonction du profil des utilisateurs finaux et les opérateurs, internes ou
externes à l’entreprise.

Utilisateur final

Cycle de vie
Utilisateur externe
Utilisateur Conditions
Utilisateur interne
Individuel/collectif
Interactions Environnement
Contrôlé
Produit
Produit Proche/lointain
Service
Culturel
Temps

Figure 39. Décomposition de l’usage selon le triptyque Produit, Utilisateur et Environnement

Un outil support a été proposé afin de faciliter la capitalisation puis l’exploitation de ces
informations relatives à l’usage du produit en cours d’exploitation. Il s’adresse à quatre types
d’utilisateurs (figure 38) :
− Les réparateurs (utilisateur intermédiaire, externe à l’entreprise),
− le client (utilisateur final),
− les experts internes à l’entreprise (utilisateurs de la production, de la maintenance…),
− les spécialistes de l’usage, sélectionnés parmi les concepteurs (utilisateurs
spécialisés).
Cet outil propose plusieurs fonctionnalités destinées à capitaliser les informations pour
chacune des 3 premières catégories d’utilisateurs, à l’aide d’interfaces utilisateurs dédiées :
− demandes d’interventions pour permettre de gérer les opérations de réparations ou
de maintenance préventive ;
− demandes d’améliorations pour gérer les retours d’expérience, les
dysfonctionnements non bloquants et les propositions d’évolution du produit ;
− documentation technique permettant l’accès aux informations relatives aux
différentes versions du produit ;

123
Rapport d’habilitation Contributions scientifiques Christophe MERLO

− boite à idées, pour proposer de nouvelles solutions, présenter des solutions

présentes dans d’autres produits… sans objectif particulier venant contraindre la
formalisation des informations ;
− forums de discussion pour échanger avec d’autres experts, promouvoir des conseils
et des bonnes pratiques.

Utilisateur final

Client
ULM Entreprise
Client Plateforme Web

Client Fabricant
Utilisateur intermédiaire
Fabricant

Fabricant
Revendeur

Revendeur
Base de données Utilisateur interne
Revendeur ULM

Figure 40. Architecture du prototype ULM

Figure 41. Ecran d’accueil du prototype ULM

Comme le montre la figure précédente, l’ensemble des informations est stocké dans une
base de données centralisée et sécurisée. Les utilisateurs spécialisés procèdent quant à eux
à des évaluations de ces informations et à leur analyse pour extraire et caractériser les
demandes d’évolution pertinentes et formaliser les idées nouvelles susceptibles de

124
Rapport d’habilitation Contributions scientifiques Christophe MERLO

constituer des innovations sur de futurs produits. De cette façon, les concepteurs traitent
directement les retours des différentes catégories d’utilisateurs du produit.
Le prototype ULM comble le besoin d’échanges entre les différents types d’utilisateurs et
l’entreprise, principalement son bureau d’études. A travers cette dynamique d’échanges,
c’est la dynamique de l’amélioration continue du produit, voire de l’innovation, qui est ainsi
renforcée. La figure suivante présente une première version de l’interface utilisateur
d’accueil.
Ces travaux sur l’usage s’intègrent simultanément dans un contexte PLM et dans la
conduite de la conception. Les SGDT couvrant les phases de développement du produit, le
concept ULM permet de couvrir les phases suivantes de fabrication et d’exploitation (incluant
utilisation et maintenance) en y capitalisant les informations produit générées. L’objectif
d’exploitation de ces informations porte sur leur prise en compte pour reconcevoir le produit
ou pour concevoir un nouveau produit en s’appuyant sur des idées potentiellement
innovantes. Nous sommes ici dans le traitement de la connaissance relative au produit telle
qu’elle est nécessaire en conduite de la conception.

Plus généralement, a été évoquée dans ce chapitre la proposition d’une méthode de

spécifications conceptuelles pour aider à concevoir des environnements d’assistance pour
les acteurs de la conception. Différents outils réalisés ont été produits en s’appuyant sur
cette méthode progressivement mise au point : des outils experts, des environnements
d’assistance à la conduite ou des outils PLM. Le respect de la méthodologie de recherche
présentée à la figure 6 impose à présent d’étudier comment de tels outils peuvent être mis
en œuvre en vue de les rendre opérationnels. C’est l’objet du prochain sous-chapitre.

3.4.4. Contribution collective : Déploiement de solutions logicielles en

entreprise

Dans le contexte industriel actuel de forte compétitivité, les entreprises se doivent de

concevoir plus rapidement, mieux et moins cher. Pour mener efficacement les phases amont
de la conception des produits, elles ont à leur disposition de multiples outils et méthodes.
Aujourd’hui, les conditions dans lesquelles ces outils sont déployés dans les organisations
constituent un facteur essentiel pour améliorer la performance de façon durable. L’intégration
de ces solutions ne peut alors se faire sans une bonne connaissance de la structuration de
l’entreprise, ni appropriation du processus de conception et de ses spécificités. Pour réussir
ce déploiement, il s’agit de s’appuyer sur des démarches génériques et personnalisables,
ainsi que d’identifier les facteurs qui permettront aux futurs utilisateurs de s’approprier la
solution qui leur est proposée.
Mes activités de recherche centrées sur la proposition de systèmes d’information pour
les acteurs de la conception ne peuvent pas être complètes sans aborder ces phases de
déploiement sous différents points de vue : la formation, la gestion du changement, les
actions de mise en œuvre…
J’ai initié cet axe de travail via une collaboration suivie avec Benoit Eynard, via le
LASMIS, à l’Université de Technologie de Troyes, puis via le laboratoire Roberval, à
l’Université de Technologie de Compiègne. Les premiers travaux ont porté sur le

125
Rapport d’habilitation Contributions scientifiques Christophe MERLO

déploiement des outils PLM en entreprise, avant d’étendre ces premiers résultats au
déploiement d’outils logiciels pour la conception aujourd’hui.

Méthode générique pour la spécification et l’implémentation d’outils PLM

Les systèmes PLM déployés au sein des entreprises sont généralement des systèmes
d’information préexistants, développés pour répondre au besoin du plus grand nombre. La
problématique qui se pose dans ce cas de figure est une problématique d’adaptation
concourante entre le système PLM et l’organisation utilisatrice. Les spécifications qui
peuvent être élaborées n’ont pas pour but de concevoir le système PLM mais de décrire
l’organisation et son fonctionnement en vue de spécifier comment il faut configurer et faire
évoluer le système PLM.
J’ai mené plusieurs travaux avec Benoit Eynard [Eynard et al. 02] visant à définir une
méthode générique de spécification des systèmes PLM. Cette méthode s’appuie sur le
formalisme UML [OMG 97] [Booch et al. 99] en vue d’être capable de modéliser les actions
des acteurs en identifiant les entrées et les sorties, ou à l’inverse de modéliser les données à
gérer et les liens qui les unissent. La méthode se décompose donc en 3 étapes principales :
− Etape 1 : identification de l’organisation et des rôles génériques
L’objectif est d’identifier les futures catégories d’utilisateurs (les rôles) et de définir pour
chacune d’elles les tâches qu’elles devront effectuer. Ce travail s’appuie sur des approches
de type réingénierie de processus (BPR, Business Process Reengineering, [Hammer &
Champy 93] ; [Scheer 99]) et nécessite la réalisation d’interviews auprès de responsables et
d’acteurs métiers des départements impactés par le système PLM, par exemple des
concepteurs mécaniciens, des ingénieurs calcul, des gammistes, des chefs de projet…
Les besoins utilisateurs sont ainsi formalisés à l’aide de diagrammes de cas d’utilisation
qui identifient les différents rôles et leurs interactions avec le système PLM (figure 40).

Promouvoir

Gérer la maturité
des données
Refuser la
promotion

Modifier

Concepteur Accéder aux

(créateur) données

Consulter

Rechercher

Valider Commenter
Equipe
Concepteur
(hors concepteur)
(autres)

Figure 42. Diagramme de cas d’utilisation et besoins fonctionnels des acteurs

126
Rapport d’habilitation Contributions scientifiques Christophe MERLO

− Etape 2 : modélisation des données techniques

Après avoir caractérisé les besoins des utilisateurs, il est nécessaire de caractériser les
données techniques qu’ils doivent manipuler : la structure arborescente du produit et de la
documentation technique associée ([Chen et al. 04] ; [Oh et al. 01]). Cette modélisation est
réalisée à l’aide de diagrammes de classe (figure 41) avec lesquels sont caractérisés les
attributs de chaque donnée technique, les opérations principales et les liens existants entre
les données.
En associant un diagramme état-transition (figure 42) à chaque donnée technique
identifiée dans le diagramme de classe, qui est une représentation statique des données
techniques, il est possible de représenter les aspects dynamiques : le cycle de vie de la
donnée technique et les principales actions qui supervisent les règles d’évolution et les
changements d’état.

Turbo-prop Module Pièce détail

Fils
Consiste en Consiste en

Père Se décompose en
Document Pièce

Consiste en

Consiste en
Fonction ch.vect. Contexte Application

Fonction

Fonction signif.
Import/ Se décompose en
Export
App. générique
Moteur Action

Réalise

Données
En charge de Instancié Processus
pertinentes
Données dans VPM
pertinentes Activité

Figure 43. Diagramme de classe de la structure produit et spécification de processus

Créer document

En cours
Rejeter
Evaluer Refuser

Partagé

Obsolète Promouvoir

Officiel

Document finalisé

Figure 44. Diagramme état-transition de la classe « Document »

127
Rapport d’habilitation Contributions scientifiques Christophe MERLO

− Etape 3 : modélisation des processus

Les processus de conception sont caractérisés par des diagrammes d’activités [Choi et
al. 03] comportant des critères temporels avec une vision macro des activités des acteurs
(figure 43). Ces diagrammes sont également utilisés pour formaliser les processus qui
pilotent l’évolution des données techniques, c’est la vision détaillée orientée donnée (i.e.
documents, exemple en figure 44). En cas de processus complexe, des diagrammes de
séquence peuvent compléter un diagramme d’activités, de façon à détailler les traitements à
appliquer sur les données techniques manipulées par les utilisateurs, pouvant donner lieu à
des développements de nouvelles fonctionnalités.

Créer document

Concevoir le profil de la pâle

[Statut du fichier du profil = « partagé »]

Conception détaillée de la pâle

[Statut des fichiers complémentaires = « partagé »]

Analyses par EF [Statut de la conception de la pâle = « Officiel »]

Figure 45. Diagramme d’activités d’un processus de conception d’une pale

Début Concevoir les profils Concevoir les pâles Analyses Ad hoc Etat Officiel Fin

Figure 46. Worflow, implémenté avec Windchill, du processus de conception d’une pale

Ces spécifications, comparées aux capacités réelles des systèmes PLM étudiés,
permettent d’identifier 3 niveaux de correspondance :
− La modélisation des données techniques par les diagrammes de classe et état-
transition identifie les classes devant être modifiées ou ajoutées et donc détermine le
niveau d’adaptation de la base de données prévue en standard : ce qui existe, ce qui
est modifiable et ce qui doit être ajouté, entrainant des développements spécifiques.
− L’identification des rôles, des interactions entre ces rôles et le système, ainsi que la
modélisation macro des processus caractérisent les fonctionnalités nécessaires :
celles qui sont présentes, celles qui doivent être adaptées ou qui sont manquantes,
d’où du développement et de la reconfiguration des interfaces utilisateurs.

128
Rapport d’habilitation Contributions scientifiques Christophe MERLO

− L’identification des rôles, la modélisation des diagrammes état-transition et des

processus détaillés donne lieu à la configuration du système : les utilisateurs, rôles et
groupes, cycles de vie et workflows.
La phase de modélisation, comportant 3 étapes, est donc suivie d’une phase
d’implémentation reprenant ces 3 étapes. Néanmoins les processus implémentés à travers
les workflow restent des processus prédéfinis. C’est pourquoi il a fallu compléter cette
méthode pour répondre à cette caractéristique de construction progressive du processus de
conception à travers deux axes complémentaires : la prise en compte de la dynamique de
gestion de projet et des mécanismes collaboratifs et émergents entre les acteurs.

Méthode de déploiement d’outils PLM en PME et prise en compte de la

collaboration
Ces travaux complètent et spécialisent la méthode générique dans un contexte PME, et
ont été menés en partenariat avec l’entreprise Ederena Concept, spécialisée dans le
développement d’équipements fabriqués en matériaux de type sandwich à structure en nid
d’abeille. Les produits couvrent des secteurs d’activités très diversifiés comme les tables de
machines outils, les mobiliers urbains ou les panneaux de structure dans le ferroviaire.
La méthode mise au point comporte également trois phases principales : la phase
d’analyse a été dissociée de la phase de spécifications détaillées de l’outil PLM afin de
pouvoir faire évoluer l’organisation de l’entreprise si nécessaire et surtout de pouvoir prendre
le temps de mener une analyse poussée des mécanismes collaboratifs existants entre les
acteurs de la conception, puis enfin la phase d’implémentation.
La phase d’analyse comporte trois étapes correspondant aux trois étapes de la méthode
générique, ainsi que trois étapes menées en parallèle qui ont pour vocation d’étudier de
façon spécifique les mécanismes collaboratifs (approche développée de façon spécifique au
chapitre 1.3.1) :
− la capture des évènements collaboratifs et de leur contexte via une participation aux
projets de conception et un rôle de participant / observateur ;
− l’analyse des données collectées pour caractériser les liens entre plusieurs
évènements collaboratifs et caractériser les mécanismes collaboratifs, amenant à
l’identification des bonnes pratiques comme des problèmes et des points à
améliorer ;
− la caractérisation des pratiques à promouvoir, via des règles ou des critères à
prendre en compte par le chef de projet ou via des processus plus détaillés mais
aussi plus flexibles, par exemple.
La phase de spécification comporte ensuite quatre étapes : l’étape de modélisation des
processus est scindée en deux étapes distinctes : la modélisation à un niveau macro est
destinée à une implémentation via les fonctionnalités de gestion de projet présents au sein
des outils PLM actuels, et la modélisation détaillée des processus est destinée à
l’élaboration des workflow de documents.
Si la phase de spécification s’appuie sur les mêmes modèles UML, la phase d’analyse
quant à elle peut s’appuyer sur d’autres formalismes en fonction du contexte industriel. Ainsi
au sein d’Ederena, les processus ont été modélisés à l’aide du formalisme IDEFØ de façon à

129
Rapport d’habilitation Contributions scientifiques Christophe MERLO

faciliter les échanges avec l’ensemble des acteurs de l’entreprise et en particulier le service
Qualité qui s’appuie sur ce formalisme.
La figure suivante récapitule cette méthode spécifique pour les PME, intégrant les
dimensions « gestion de projet » et « flexibilisation des processus de conception par l’étude
des mécanismes collaboratifs ».

Organisation et Structuration des Modélisation des Spécification de la

Définition des rôles Données Produit Flux d’information Gestion de projet
1 2 3 4

Capture des
Analyse de la Caractérisation des
évènements
collaboration Bonnes pratiques
collaboratifs 5 6 7

Implémentation des Implémentation des Implémentation du

rôles Données Produit Processus projet
8 9 10

Figure 47. Méthode de déploiement d’outils PLM en PME

En étudiant les systèmes d’information de type PLM, les méthodes proposées lors de
mes travaux n’ont pris en compte qu’une partie de la problématique du déploiement. Ces
méthodes explorent la phase d’analyse initiale, puis la phase de spécification et
d’implémentation des outils. Toutefois, elles ne sont pas applicables à d’autres types d’outils
logiciels, et plus encore, elles n’abordent ni la question de la gestion du changement qui doit
amener les utilisateurs à être opérationnels sur les nouveaux outils : cela inclut par exemple
l’apprentissage des connaissances générales à partager par les acteurs et la direction, la
formation aux outils proprement dits, la maîtrise des compétences nécessaires à leur bonne
utilisation et des nouvelles règles de fonctionnement. Ce sera l’objet de futurs travaux.

Dans ce chapitre, j’ai abordé l’axe de la conception et de la mise en œuvre

d’environnements d’assistance, en suivant deux sous-axes complémentaires : la mise au
point de systèmes d’information pour la conduite et l’étude des systèmes de type PLM.
La proposition d’environnements pour la conduite constitue une application directe de
mon premier axe consacré à la mise en œuvre de la conduite de la conception. Il a permis la
caractérisation de méthodes de spécification, intitulées « méthodes de spécifications
conceptuelles ». Ces méthodes ont été appliquées pour proposer plusieurs prototypes
logiciels visant à démontrer l’applicabilité des concepts proposés en conduite.
L’étude des systèmes PLM a également donné lieu à l’élaboration de méthodes
d’analyse et de spécifications pour les systèmes proposés par les éditeurs logiciels, mais
aussi la proposition d’outils pour les acteurs de la conception dans un contexte PLM.
Ces travaux intègrent également les résultats développés par l’axe consacré à l’étude de
la collaboration entre acteurs, puisque l’application des méthodes développées permet d’une
part de compléter la caractérisation des vues utilisateurs et métier nécessaires pour spécifier
l’environnement d’assistance pour la conduite, et d’autre part d’améliorer la caractérisation
des processus détaillés dans les systèmes PLM lors des phases de spécification.

130
Rapport d’habilitation Contributions scientifiques Christophe MERLO

La figure 46 synthétise ainsi l’ensemble des axes de recherche que j’ai explorés et
propose une cartographie des principaux apports qui permet de les positionner suivant les
différentes étapes de la méthodologie de recherche suivie. Dans le chapitre suivant, je
rappelle ces apports et leurs limites, de façon à mettre en évidence les travaux qui restent à
poursuivre.

Observation Modélisation Formalisation Déploiement

Analyse solutions

Axe
Méthodologie GRAI Ingénierie
Système

Modélisation du système de conception

Modélisation des connaissances
Audits Modélisation du système d’information
Interviews Implantation, Mise en
œuvre de la conduite

Axe
Environnements Méthodes pour la mise en œuvre d’environnements d’assistance
d’Assistance

Méthode de spécification Architecture

Expertise métier conceptuelle Interopérabilité
Méthodes
Vue utilisateur d’implantation

Axe
Méthode d’analyse de la collaboration entre acteurs
Hommes

Analyse des Capitalisation des

évènements bonnes pratiques
Observation collaboratifs
participante Réingénierie des processus
Gestion du changement

Figure 48. Axe mise en œuvre d’environnements d’assistance et couplage des 3 axes de recherche

131
Rapport d’habilitation Contributions scientifiques Christophe MERLO

3.5. SYNTHESE ET PERSPECTIVES

3.5.1. L’affirmation d’un schéma de recherche

L’ensemble des travaux menés et présentés précédemment procèdent d’objectifs

complémentaires qui concourent vers un objectif global et unique : l’étude d’environnements
d’assistance aux acteurs de la conception destinés à supporter la conduite de la conception
dans un environnement PLM.
J’ai démontré que ces travaux sont structurés autour de trois axes complémentaires
(figure 40). Le premier axe étudié, l’axe « système », se focalise sur la conduite de la
conception et s’appuie sur une approche systémique et la modélisation d’entreprise pour
proposer une méthodologie destinée à transformer l’entreprise vers cette démarche de
conduite. Ce premier axe est donc caractérisé par une approche descendante. Focalisée sur
la conduite par les chefs de projet et les responsables intermédiaires, complexe et
nécessitant un environnement informatique adéquat, ces travaux ne sont pas suffisants en
eux-mêmes pour permettre aux acteurs une mise en œuvre satisfaisante des mécanismes
de conduite.
C’est pourquoi j’ai proposé deux axes complémentaires : l’axe des « acteurs » qui se
focalise sur l’étude des mécanismes collaboratifs entre acteurs de façon à intégrer le facteur
humain parmi les paramètres entraînant la prise de décision en conduite. Cet axe repose
entièrement sur une approche ascendante qui vient donc compléter les résultats
scientifiques du premier axe en rendant plus robustes les modèles et méthodes proposées
tout en préparant leur application. Ces travaux mettent aussi en évidence les besoins
fonctionnels des « acteurs de la conception » qui se traduisent dans les environnements
d’assistance étudiés dans le troisième axe. La conception de systèmes d’information
supports aux acteurs de la conception constitue l’objectif principal de ma thématique de
recherche. Cet axe essentiel doit intégrer de multiples points de vue : l’intégration de la
conduite de la conception mais aussi les besoins métiers des acteurs ; les chefs et
responsables de projets comme les concepteurs (au sens de la conduite) ; l’élaboration de
nouveaux systèmes d’information mais aussi la prise en compte des systèmes existants
comme les systèmes PLM ; enfin la proposition de nouveaux outils mais aussi les conditions
de leur mise en œuvre effective au sein des entreprises.

A travers les expérimentations et les projets menés, c’est également l’intérêt de la

démarche de recherche proposée qui a été confirmée (figure 4). Des phases initiales
d’observation et d’analyse menées dans un environnement industriel permettent d’enrichir
considérablement une problématique donnée. Par ailleurs une fois les résultats scientifiques
établis, leur application s’en trouve renforcée à travers l’élaboration de spécifications
logicielles très détaillées et basées sur les besoins utilisateurs, mais aussi à travers la
formalisation de scénarios d’expérimentations permettant un réel retour d’expérience.

133
Rapport d’habilitation Contributions scientifiques Christophe MERLO

3.5.2. Perspectives : vers des environnements d’assistance

interopérables
Ma contribution dans le domaine de la conduite de la conception tient essentiellement
dans la proposition de la méthodologie GRAI R&D en vue de déployer cette approche dans
l’entreprise. Bien que cette méthodologie intègre toutes les étapes de l’analyse au
déploiement et à la spécification d’un système d’information adapté, elle a été élaborée en
prenant comme périmètre l’entreprise étendue.
La mondialisation de l’économie a progressivement amené les entreprises à collaborer
pour développer de nouveaux produits. La co-conception est un enjeu désormais important
qu’il est nécessaire de prendre en compte. Toutefois la collaboration multi-partenaires
représente un risque dû aux contraintes induites par leurs liens de dépendance mutuelle. La
question de la collaboration est donc fondamentale à chacune des étapes du développement
du produit comme de la fabrication : l’étude de marché, la conception, la fabrication, la
commercialisation et la distribution. Il est nécessaire de mettre au point des méthodes et des
outils pour aider les responsables avant, pendant et après les projets de développement de
produits. Par ailleurs la collaboration implique des échanges de données et d’informations.
Mais ces échanges ne peuvent avoir lieu sans un diagnostic stratégique clair de
l’environnement extérieur de l’entreprise, des opportunités et des menaces, ainsi que
l’environnement interne, ses forces et ses faiblesses. Une fois ce diagnostic réalisé et les
protocoles de collaboration établis, l’entreprise devra chercher de nouveaux partenaires, les
choisir, et enfin négocier et signer des contrats [Liker 03] [Womack et al. 91].
Durant ces phases de contact et de rapprochement, l’entreprise doit identifier les
tactiques pertinentes pour la réalisation de ses propres objectifs stratégiques permettant à
chaque acteur du réseau d’atteindre un équilibre « gagnant-gagnant » [Womack & Jones
03]. C’est certainement l’une des étapes tout à la fois centrale et extrêmement difficile de
l’établissement de la collaboration. La collaboration effective peut dès lors commencer,
durant les phases de conception et d’industrialisation. Ces observations montrent clairement
qu’une approche scientifique est nécessaire pour analyser et comprendre ces situations
complexes de façon à apporter une assistance pertinente aux responsables de l’entreprise.
En outre la conception collaborative avec des partenaires, nouveaux ou anciens, n’est qu’un
aspect de la co-conception, il faut aussi intégrer la phase d’industrialisation durant laquelle
les partenaires doivent collaborer de façon quotidienne et interagir en respectant leurs
objectifs individuels et collectifs. Le travail collectif concerne les partenaires en réseau sur
des aspects stratégiques, tactiques et opérationnels [Shore & Venkatachalam 00]. Quand le
produit est conçu et industrialisé, l’enjeu pour l’entreprise consiste à co-gérer la fabrication
avec l’ensemble des partenaires en respectant les contraintes de coût, qualité et délais, et
cela d’autant plus que certains partenaires n’ont pas participé aux phases de
développement. Ainsi les choix effectués par les responsables pour constituer un réseau de
partenaires doivent considérer non seulement les partenaires de la conception mais aussi
les partenaires impliqués tout au long du cycle de vie du produit, en fabrication notamment,
dès le début des projets de développement [Zolghadri et al. 06].
Dans ce contexte de co-conception, la méthodologie GRAI R&D doit être adaptée pour
étendre la conduite de la conception à l’ensemble du réseau de partenaires impliqués dans
le développement d’un produit. En effet, la conduite du réseau ajoute plusieurs types de
contraintes nouvelles qui n’existent pas quand l’entreprise développe de façon autonome un

134
Rapport d’habilitation Contributions scientifiques Christophe MERLO

produit. Lors d’un projet de co-conception, chaque entreprise gère deux niveaux distincts de
conception : un niveau purement interne, au sein duquel l’entreprise gère comme un projet
interne la conception des sous-systèmes dont elle a la responsabilité ; et un niveau externe,
qui s’intègre au projet global de développement, et qui garantit la synchronisation du projet
interne avec le projet externe. Les différentes étapes de modélisation du système de
conception du réseau de partenaires ne peut donc pas être menée comme une simple
addition de modèles réalisés au sein de chaque entreprise, ni comme une modélisation
globale. Les deux niveaux doivent être étudiés pour comprendre quelles sont les relations
entre eux et définir comment les modèles proposés doivent évoluer : les modèles du
système décisionnel et du système technologique, mais aussi les modèles des
connaissances puis du système d’information fédérateur.

La co-conception impacte également l’axe des « acteurs » en renforçant la nécessité de

maîtriser les mécanismes collaboratifs entre des acteurs qui appartiennent à des entreprises
différentes. Il ne suffit pas de conduire le processus de développement de produit dans le
cadre de l’entreprise étendue mais aussi de favoriser la collaboration inter-entreprise afin de
conserver la flexibilité de ce processus [Pardessus 01]. Aux enjeux individuels et collectifs -
jeux de pouvoir, motivation, ambitions - présents au sein de l’entreprise s’ajoutent les
objectifs propres de chaque partenaire : objectifs stratégiques et locaux, intérêts dans le
partenariat, nature des partenariats et culture d’entreprise, etc. De véritables réseaux
informels d’acteurs [Krackhardt & Hanson 93] se développent parfois de façon volontariste et
parfois de façon spontanée, émergente. En conduite, il est important pour les responsables
de favoriser ce type de réseaux de façon à améliorer la satisfaction de certains objectifs de
conception, techniques, collaboratifs, … [Krackhardt 94]. Les comprendre et les modéliser
répond à un double objectif : poursuivre la validation de la méthode d’analyse des
mécanismes collaboratifs proposée lors de la thèse de Guillaume Pol d’une part ; et d’autre
part participer à l’évolution de la méthode GRAI Ingénierie par l’identification des spécificités
de la collaboration en co-conception – flux d’information, prise de décision, partage de
connaissances par exemple -.

Dans l’axe « environnement d’assistance », les spécifications d’un système d’information

pour la conduite ont permis une modélisation fonctionnelle, sans aborder explicitement la
question de l’implémentation en entreprise. Les prototypes logiciels réalisés jusqu’à présent
prennent le parti d’élaborer un outil logiciel unique assurant le support de la conduite et
devenant le noyau fédérateur des acteurs. Seul le prototype IPPOP envisage la connexion à
des outils experts à travers des API standardisées afin de partager des informations
communes.
Malgré tout mes autres travaux relatifs aux environnements d’assistance témoignent
d’une réalité plus complexe. Les projets de conception couvrent une grande partie du cycle
de vie d’un produit, de l’identification du besoin jusqu’à la définition complète du produit et de
ses procédés d’industrialisation. De nombreux systèmes informatiques coexistent pour
supporter les activités de conception :
− les logiciels spécialisés, ou applications expertes, qui correspondent aux différents
besoins métiers des acteurs et aident à la prise de décision technique : la nécessaire
traçabilité de l’évolution du produit et du processus au sein du système technologique

135
Rapport d’habilitation Contributions scientifiques Christophe MERLO

doit prendre en compte les informations gérées par ces logiciels experts afin d’éviter
des redondances ;
− les systèmes PLM qui assurent la gestion des données techniques et du cycle de vie
du produit, la gestion de la configuration produit et de la documentation : non
seulement ils assurent eux-mêmes une traçabilité des processus de conception et
des données produits, mais ils assurent également une traçabilité partielle des
décisions prises et leur suivi ;
− les outils de la gestion de projet et de gestion des portefeuilles de projets : ils gèrent
directement des fonctions et des informations de coordination ;
− les outils d’aide au travail collectif : collecticiels et systèmes de Gestion Electronique
de Documents (GED) : ils supportent l’application des référentiels qualité de
l’entreprise et les principaux flux collaboratifs entre les acteurs ;
− enfin les systèmes de gestion des connaissances pour la conception, systèmes
experts, de retour d’expérience ou mémoires projet : supports aux acteurs,
coordonnateurs comme concepteurs.
Du fait de cette complexité, je perçois les environnements d’assistance proposés jusqu’à
présent comme des démonstrateurs et non comme des systèmes d’information adaptés à
une réelle mise en œuvre. Il faut donc étudier l’intégration entre la proposition de nouveaux
outils ou systèmes avec les logiciels et systèmes d’information existants au sein des
entreprises. Toutefois, considérer ce problème uniquement du point de vue opérationnel
n’est pas satisfaisant car elle conduit à la multiplication d’interfaces spécialisées pour chaque
outil étudié ou cas d’application envisagé. Il est nécessaire d’explorer des solutions
génériques qui peuvent être déployées avec un minimum d’efforts dans des situations
différentes. La problématique de l’interopérabilité est centrale dans la perspective de rendre
applicable la conduite de la co-conception au sein d’un réseau de partenaires, et ce dans un
contexte PLM.
La capacité des systèmes industriels actuels à être interopérables pour faciliter les
échanges d’informations est faible car s’appuyant au mieux sur des échanges de fichiers via
des formats pauvres du point de vue sémantique. De ce point de vue les systèmes actuels
répondent de manière incomplète au besoin croissant d’intégration des connaissances qui
permette une véritable collaboration des différents métiers lors du développement d’un
produit entre plusieurs partenaires. Ils ne répondent pas non plus à la nécessité de
coordonner ces différentes équipes engagées dans la conception du produit, avec comme
corollaire de pouvoir tracer les activités essentielles pour mieux suivre l’avancement des
projets. Ces conditions impliquent également de pouvoir mieux prendre en compte les
activités collaboratives et/ou informelles, riches d’échanges d’informations et de partage de
connaissances entre acteurs.

Compte-tenu des limitations énoncées jusqu’à présent, l’interopérabilité doit être étudiée
à plusieurs niveaux. Non seulement les outils et systèmes proposés doivent être
interopérables entre eux et avec les outils et systèmes existants pour faciliter les échanges
de données, mais il faut considérer également les processus et les organisations impliquées
dans les situations de co-conception. L’interopérabilité est par définition la capacité pour
deux systèmes ou plus à échanger des informations et à accéder réciproquement à leurs

136
Rapport d’habilitation Contributions scientifiques Christophe MERLO

fonctionnalités. Il existe trois approches pour établir l’interopérabilité : l’approche intégrée

basée dur un format commun, l’approche unifiée basée sur un meta-modèle pour la mise en
correspondance, et enfin une approche fédérée permettant aux systèmes de s’adapter
automatiquement. L’interopérabilité d’entreprise s’intéresse prioritairement aux organisations
en réseau. La recherche s’appuie actuellement sur plusieurs axes complémentaires
combinant les approches d’ingénierie basée sur les modèles, les ontologies pour la
médiation de processus collaboratifs, les architectures orientées services, de façon à
développer des systèmes d’inforamtion collaboratifs orchestrés par médiation. C’est ainsi
que l’approche MDA (Model Driven Architecture, [OMG 03]) s’appuie sur l’utilisation de
modèles et de leurs transformations pour concevoir et implanter différents systèmes.
L’approche MDI (Model Driven Interoperability, [Bouray 07] s’inspire de cette approche pour
préconiser des modèles d’entreprise et l’utilisation de techniques de transformations de
modèles pour relier les différents niveaux d’abstraction des organisations aux outils.
Le projet ISTA3 et la thèse récemment engagée avec Mickael Romain constituent une
illustration particulièrement pertinente de cette idée. Le concept d’interopérabilité d’entreprise
permet de concilier les approches de modélisation d’entreprise (telles qu’étudiées dans l’axe
système) avec les approches de spécifications logicielles au travers des modèles MDI qui
définit un cadre générique. L’application au PLM de ces recherches renforce les travaux
menés jusqu’à en PLM pour les intégrer complètement dans ce même cadre.
Ainsi ce projet concerne les échanges de données techniques entre les systèmes PLM
de deux partenaires aéronautiques. En pratique, il s’agit d’échanger des données CAO entre
deux systèmes PLM mais aussi les méta-données qui leur sont associées, comme par
exemple la version des articles CAO échangés et leur état (relatif à leur cycle de vie).
Comme les organisations sont différentes, le partenaire recevant les articles CAO en a une
vision différente et n’aura pas besoin de toutes les méta-données envoyées, de la même
façon qu’il en manquera certaines qui lui sont propres. De même les processus de
conception étant différents, certaines méta-données de même nature comme la version et
l’état auront une interprétation différente et donc des valeurs différentes sur chacun des deux
systèmes.

Dans le cadre de mes perspectives de recherche, l’étude de la problématique de

l’interopérabilité d’entreprise a pour but de proposer une démarche générique de
spécifications puis de déploiement d’environnements d’assistance susceptibles de prendre
en compte les contraintes opérationnelles d’implantation en entreprise. Cette implantation ne
peut toutefois être effective qu’avec leur acceptation par les acteurs. Cette dernière phase
sera étudiée à travers la thèse de Stéphanie Mahut ce qui aboutira à la formalisation d’une
démarche complète comprenant l’étude d’environnements d’assistance centrés utilisateurs,
leurs spécifications, la proposition d’architectures interopérables, leur développement et leur
implantation, jusqu’à la conduite du changement auprès des futurs utilisateurs.
Ce travail de thèse vise à aider au déploiement et à l’appropriation d’outils
méthodologiques en conception et ingénierie système. Il a pour but de développer une
démarche de déploiement d’outils méthodologiques en y intégrant notamment les
problématiques d’appropriation par une organisation et d’utilisabilité des interfaces et des
formations. L’objectif est aussi d’en étudier la mise en œuvre à travers la confrontation de la

137
Rapport d’habilitation Contributions scientifiques Christophe MERLO

suite d’outils méthodologiques développée par l’entreprise TDC transfert de Connaissances

avec des situations de terrain.

En conclusion mes travaux de recherche sont centrés sur l’étude et la proposition

d’environnements d’assistance pour les acteurs de la conception dans un contexte de
conduite et s’articulent suivant un axe « système » qui est centré sur la problématique de la
conduite, un axe « acteurs » qui est centré sur l’étude des mécanismes collaboratifs, et enfin
un axe « environnements d’assistance » qui s’appuie sur les 2 axes précédents pour
concevoir les outils logiciels supports aux acteurs. Depuis les premiers travaux réalisés,
deux nouvelles perspectives doivent être associées : la généralisation de la co-conception
au sein d’un réseau de partenaires et le passage d’une problématique de gestion du
développement d’un produit à une problématique de gestion globale du cycle de vie du
produit (approche PLM).
Ces nouvelles perspectives, ramenées sur les trois axes précédents, permettent de
définir trois nouvelles directions qui conditionnent mes futurs travaux (figure 47) :
− l’extension de la méthodologie GRAI R&D à la co-conception sur les axes
« système » et « acteurs »,
− l’intégration de la problématique de l’interopérabilité d’entreprise à l’axe
« environnements d’assistance »,
− la généralisation d’une démarche de conception d’environnements d’assistance
intégrant les problématiques d’appropriation et d’utilisabilité.
Les deux dernières de ces directions font déjà l’objet de travaux scientifiques via deux
thèses de doctorat et deux projets ou partenariats industriels.

Axe Système en co-conception

Interopérabilité d’entreprise
Appropriation

Axe Environnements d’assistance interopérables et

Collaborations au sein de réseaux d’acteurs utilisabilité

Axe Acteurs

Figure 49. Evolution des axes de recherche

138