Système intégré pour la modélisation, l'échange et le

N°Ordre : 02 ISAL 0052 Année 2002

THÈSE

présentée devant

L’INSTITUT NATIONAL DES SCIENCES APPLIQUÉES DE LYON

pour obtenir

LE GRADE DE DOCTEUR

FORMATION DOCTORALE : INFORMATIQUE ECOLE DOCTORALE : INFORMATIQUE ET INFORMATION POUR LA SOCIETE

PAR

Imad EL KHALKHALI

SYSTÈME INTÉGRÉ POUR LA MODÉLISATION, L’ÉCHANGE ET LE PARTAGE DES DONNÉES DE

PRODUITS

Soutenue le 8 Octobre 2002 devant la Commission d’Examen

Jury : MM. M. MARTINEZ, Co-Directeur de thèse J. FAVREL, Directeur de thèse

P. GHODOUS, LIGIM Lyon, Co-Directeur de thèse D. NOYES, ENIT Tarbes, Rapporteur

C. CAUVET, IUP Aix-Marseille, Rapporteur A. BOULMAKOUL, FSTM Mohammedia, Examinateur

Cette thèse a été préparée au laboratoire de Productique et Informatique des Systèmes Manufacturiers (PRISMa) de l’INSA de Lyon.

SOMMAIRE

INTRODUCTION GÉNÉRALE........................................................................................................................................................................ 1

1ÈRE PARTIE : ETAT DE L'ART ET APPROCHE PROPOSÉE

CHAPITRE 1 : L'ENTREPRISE MANUFACTURIERE : ENVIRONNEMENT ET NOUVELLES FORMES D'ORGANISATION

1. INTRODUCTION ........................................................................................................................................................................................... 5

2. LES FORCES DE L’ENVIRONNEMENT................................................................................................................................................... 6

2.1 EXIGENCES ACCRUES DES CONSOMMATEURS............................................................................................................................................. 62.2 GLOBALISATION DES MARCHÉS .................................................................................................................................................................. 82.3 CONCURRENCE AXÉE SUR LA PRODUCTIVITÉ ET LA QUALITÉ................................................................................................................... 102.4 ACCÉLÉRATION DU DÉVELOPPEMENT ET DE LA DIFFUSION DE LA TECHNOLOGIE.................................................................................... 12

3. LES PRATIQUES ÉMERGENTES ............................................................................................................................................................ 13

3.1 L’ENTREPRISE VIRTUELLE........................................................................................................................................................................ 133.1.1 Caractéristiques fondamentales ....................................................................................................................................................... 133.1.2. Types de L’Entreprise Virtuelle ....................................................................................................................................................... 17

3.2 L’INGÉNIERIE SIMULTANÉE ...................................................................................................................................................................... 173.2.1 L’approche linéaire et son abandon................................................................................................................................................. 173.2.2 L’approche simultanée ..................................................................................................................................................................... 193.2.3 Outils informatiques de mise en œuvre............................................................................................................................................. 21

4. CONCLUSION .............................................................................................................................................................................................. 25

2EME PARTIE : METHODOLOGIE ET MISE EN OEUVRE INFORMATIQUE

CHAPITRE 2 : MODÉLISATION, ÉCHANGE ET PARTAGE DE DONNÉES DE PRODUIT : LA TECHNOLOGIE STEP

1. INTRODUCTION ......................................................................................................................................................................................... 27

2. ECHANGE, PARTAGE ET INTÉGRATION DE DONNÉES................................................................................................................. 28

3. LES DIFFÉRENTS ASPECTS DE LA TECHNOLOGIE STEP............................................................................................................. 32

3.1 MÉTHODES DE DESCRIPTION DE L’INFORMATION : LE LANGAGE EXPRESS............................................................................................ 333.1.1 Origine .............................................................................................................................................................................................. 333.1.2 Les fondements du langage EXPRESS.............................................................................................................................................. 343.1.3 La notation graphique EXPRESS-G ................................................................................................................................................ 363.1.4 Intérêt d’EXPRESS ........................................................................................................................................................................... 37

3.2 MÉTHODES DE MISE EN ŒUVRE................................................................................................................................................................. 383.2.1 Représentation des instances sous forme de fichier neutre .............................................................................................................. 393.2.2 L’interface SDAI .............................................................................................................................................................................. 403.2.3 Génération d’applications à partir d’un modèle EXPRESS............................................................................................................. 41

3.3 LES MODÈLE DE DONNÉES STEP............................................................................................................................................................... 413.3.1 Les ressources intégrées ................................................................................................................................................................... 41

3.3.1.1 Les Ressources Intégrées Génériques ....................................................................................................................................... 413.3.1.3 Les Ressources Intégrées d’Application ................................................................................................................................... 42

3.3.2 Les protocoles d’application STEP................................................................................................................................................... 433.3.3 Les constructions interprétées applicatives ...................................................................................................................................... 50

3.4 LES TESTS DE CONFORMITÉ....................................................................................................................................................................... 50

4. CONCLUSION .............................................................................................................................................................................................. 51

CHAPITRE 3 : PRÉCISION ET APPROCHE DE LA PROBLÉMATIQUE

1. INTRODUCTION ................................................................................................................................................................................... 53

2. PRÉCISION DE LA PROBLÉMATIQUE ................................................................................................................................................. 54

3. MODÈLES ET APPROCHES POUR LA CONCEPTION ET LA FABRICATION INTÉGRÉES................................................... 56

3.1 LES MODÉLISATIONS PRODUIT-PROCESSUS.............................................................................................................................................. 563.1.1 La théorie des Domaines .................................................................................................................................................................. 563.1.2 Le Modèle Intégré de Définition de Système Mécanique (MIDSYM)............................................................................................... 573.1.3 Le modèle par couche ....................................................................................................................................................................... 573.1.4 Le modèle FBS ................................................................................................................................................................................. 583.1.5 Le modèle produit de MOKA............................................................................................................................................................ 583.1.6 Modèle pour la capitalisation et la réutilisation des connaissances................................................................................................ 60

3.2 APPROCHES POUR LA MODÉLISATION MULTI-POINTS DE VUE DES PRODUITS ........................................................................................... 623.2.1 Approche à modèle unique ............................................................................................................................................................... 623.2.2 Approche multi-modèles ................................................................................................................................................................... 623.4.3 Avantages et inconvénients des deux approches .............................................................................................................................. 63

4. VERS UNE APPROCHE GLOBALE ......................................................................................................................................................... 64

5. CONCLUSION .............................................................................................................................................................................................. 65

CHAPITRE 5 : INFRASTRUCTURE POUR LA MODÉLISATION, L’ÉCHANGE ET LE PARTAGE DES DONNÉES DE PRODUIT

CHAPITRE 4 : MÉTHODOLOGIE POUR LA MODÉLISATION INTÉGRÉE PRODUIT-PROCESSUS

1. INTRODUCTION ......................................................................................................................................................................................... 67

2. ELÉMENTS DE CONSTRUCTION DE LA MÉTHODOLOGIE .......................................................................................................... 68

3. DESCRIPTION DES MODÈLES................................................................................................................................................................ 71

3.1 MODÈLE DE PRODUIT................................................................................................................................................................................ 713.1.1 Modèle de Besoin.............................................................................................................................................................................. 733.1.2 Modèle Fonctionnel .......................................................................................................................................................................... 753.1.3 Modèle Comportement...................................................................................................................................................................... 773.1.4 Modèle de Structure.......................................................................................................................................................................... 78

3.2 MODÈLE DE PROCESSUS............................................................................................................................................................................ 843.2.1 Types de processus en entreprise...................................................................................................................................................... 843.2.2 Définition du concept de Processus.................................................................................................................................................. 863.2.3 Les composants du processus ........................................................................................................................................................... 87

3.2.3.1 L’activité ................................................................................................................................................................................... 873.2.3.2 Les entrants / sortants d’un processus....................................................................................................................................... 893.2.3.3 Les Ressources.......................................................................................................................................................................... 903.2.3.4 L’état ......................................................................................................................................................................................... 903.2.3.5 Synthèse .................................................................................................................................................................................... 91

3.3 COUPLAGE ENTRE LE MODÈLE DE PRODUIT ET PROCESSUS...................................................................................................................... 93

4. EXEMPLE DE DÉVELOPPEMENT D’UN CONNECTEUR ÉLECTRIQUE...................................................................................... 93

4.1 CONSTITUTION DU GROUPE DE PROJET ..................................................................................................................................................... 934.2 INSTANCIATION DU MODÈLE DE BESOIN ................................................................................................................................................... 954.3 INSTANCIATION DU MODÈLE FONCTIONNEL ............................................................................................................................................. 964.4 INSTANCIATION DU MODÈLE DE COMPORTEMENT.................................................................................................................................... 974.5 INSTANCIATION DU MODÈLE DE STRUCTURE............................................................................................................................................ 984.6 INSTANCIATION DU MODÈLE DE PROCESUS ............................................................................................................................................ 101

5. CONCLUSION ............................................................................................................................................................................................ 103

1. INTRODUCTION ......................................................................................................................................................................................... 104

2. NÉCESSITÉ D’UNE INFRASTRUCTURE .............................................................................................................................................. 105

2.1 BESOINS ORGANISATIONNELS .................................................................................................................................................................. 1072.2 BESOINS TECHNOLOGIQUES ..................................................................................................................................................................... 108

2.2.1 Plate-forme de communication ........................................................................................................................................................ 1082.2.2 Gestion de stockage et partage de données ..................................................................................................................................... 1122.2.3 Solution pour l’interopérabilité des modèles................................................................................................................................... 113

3. CHOIX D’UNE ARCHITECTURE............................................................................................................................................................ 115

3.1 ARCHITECTURE À 2 NIVEAUX : CLIENT LOURD-SERVEUR....................................................................................................................... 1153.2 ARCHITECTURE À 3 NIVEAUX : CLIENT LÉGER- SERVEUR WEB- SERVEUR DE DONNÉES..................................................................... 1163.3 COMPARAISON DES DEUX TYPES D’ARCHITECTURE................................................................................................................................. 117

4. ARCHITECTURE DE L’INFRASTRUCTURE PROPOSÉE ................................................................................................................ 119

4.1 EXPRESS-G MODELER ........................................................................................................................................................................... 1214.1.1 Le Langage JAVA............................................................................................................................................................................. 1214.1.2 Fonctionnement ................................................................................................................................................................................ 1234.1.3 Fonctionnalités ................................................................................................................................................................................. 124

4.2 INTERFACE D’ACCÈS AUX DONNÉES DE PRODUIT.................................................................................................................................... 1264.2.1 Le langage PHP ............................................................................................................................................................................... 1264.2.2 Fonctionnement ................................................................................................................................................................................ 1284.2.3 Fonctionnalités ................................................................................................................................................................................. 129

5. SCÉNARIO DE DÉMONSTRATION........................................................................................................................................................ 133

5.1 RECHERCHE DE PARTENAIRES .................................................................................................................................................................. 1345.2 SOUMISSION ET NÉGOCIATION.................................................................................................................................................................. 1355.3 RÉALISATION DU PROJET .......................................................................................................................................................................... 135

6. CONCLUSION .............................................................................................................................................................................................. 137

CONCLUSION GÉNÉRALE .......................................................................................................................................................................... 139

BIBLIOGRAPHIE ................................ ................................................................................................................................ ............................ 143

LISTE DES FIGURES

Figure 1.1 - Illustration schématique d'une Entreprise Virtuelle .....................................................................................15Figure 1.2 - Gain de temps apporté par la démarche simultanée.....................................................................................20Figure 1.3 - Principales fonction couvertes par un ERP...................................................................................................24

Figure 2.1 - St ructure de la norme STEP.............................................................................................................................32Figure 2.2 - Un exemple de hiérarchie de classes EXPRESS ..........................................................................................34Figure 2.3 - Un modèle de données contraint .....................................................................................................................35Figure 2.4 -Représentations en EXPRESS-G d’un modèle de données [SAR99]........................................................37Figure 2.5 - Exemple d’un fich ier physique........................................................................................................................39Figure 2.6 - Cycle de développement d’un AP...................................................................................................................43Figure 2.7 - Quelques Protocoles d’Application ................................................................................................................45

Figure 3.1 - Pluridisciplinarité de la conception de produit .............................................................................................54Figure 3.2 - Le chromosome [AND91]................................................................................................................................56Figure 3.3 - Le méta modèle Produit de MOKA [MOK99] .............................................................................................59Figure 3.4 - Modèle de processus proposé par harani [HAR97]......................................................................................61Figure 3.5 - Représentation de l’approche à modèle unique ............................................................................................62Figure 3.6 - Représentation de l’approche multi-modèles ................................................................................................63

Figure 4.1 - Etapes de construction des modèles liés aux points de vue........................................................................69Figure 4.2 - Représentation des définitions de Besoin, Fonction, Comportement et Structure..................................70Figure 4.3 – Modèle de Produit .............................................................................................................................................71Figure 4.4 - Modèle de Besoin exprimé en EXPRESS-G.................................................................................................73Figure 4.5 - Représentation du Modèle Fonctionnel en utilisant le langage EXPRESS-G.........................................76Figure 4.6 - Modèle de Comportement représenté par le langage EXPRESS_G. .......................................................77Figure 4.7 - Modèle de structure exprimé en EXPRESS-G..............................................................................................79Figure 4.8 - Structure hiérarchique d’un Produit assemblé...............................................................................................82Figure 4.9 - Modèle d’Assemblage exprimé en EXPRESS-G........................................................................................83Figure 4.10 - Modèle de Processus exprimé en EXPRESS-G..........................................................................................91Figure 4.11 – Couplage entre le modèle de Produit et de Processus ..............................................................................93Figure 4.12 – Instanciation du Modèle de Besoin par deux points de vue différents ..................................................95Figure 4.13 – Instanciation du Modèle Fonctionnel et son lien avec le modèle de Besoin ........................................96Figure 4.14 – Instanciation du modèle de Comportement et son lien avec le modèle Fonctionnel ..........................97Figure 4.15 – Instanciation du modèle de Structure et son lien avec le modèle de Comportement .........................98Figure 4.16 – Instanciation du modèle d’assemblage........................................................................................................99Figure 4.17 - Vue générique sur les instances et liaisons entre modèles......................................................................100 Figure 4.18 – Instanciation du modèle de Processus (Séquence d’assemblage)........................................................102

Figure 5.1 - Modules de l’Infrastructure Support à l’Entreprise Virtuelle......................................................... 108Figure 5.2 - Architecture Client-Serveur à 2 Niveaux ...................................................................................... 116Figure 5.3 - Architecture Client-Serveur à 3 Niveaux ...................................................................................... 117Figure 5.4 - Architecture de l’infrastructure support à l’Entreprise Virtuelle.................................................... 120Figure 5.5 - Schéma de fonctionnement d’EGM.............................................................................................. 124Figure 5.6 - L’interface Graphique EGM......................................................................................................... 125Figure 5.7 - Insertion d’objets EXPRESS-G.................................................................................................... 125Figure 5.8 - L’Editeur EXPRESS .................................................................................................................... 126Figure 5.9 - Exemple simple d’un script PHP.................................................................................................. 128Figure. 5.10 - Schéma de fonctionnement d’une requête de IADP ................................................................... 129Figure 5.11 - Accès sécurisé à l’IADP ........................................................................................................... 130Figure 5.12 - Upload d’un fichier ................................................................................................................... 131Figure 5.13 - Download d’un fichier................................................................................................................ 132Figure 5.14 - Visualisation en ligne ................................................................................................................ 133Figure 5.15 - Accès au dossier d’Appel d’Offres par le partenaire ................................................................... 135Figure 5.16 - Résultat de recherche d’un document d’appel d’offre ................................................................. 136Figure 5.17 - Illustration schématique de l’entreprise Virtuelle considérée ..................................................... 137Figure 5.18 - Scénario de fabrication de portes entre partenaires..................................................................... 138

LISTE DES TABLEAUX

Tableau 4.1 - Définit ion partielle d’un paramètre d’un moteur électrique ...................................................................74Tableau 4.2 - Démarche de constitution du groupe de projet de développement du connecteur .............................94

Tableau 5.1 – Modules et solutions technologiques de l’Infrastructure ............................................................ 115Tableau 5.2 - Types de fichiers supportés par IADP ........................................................................................ 132Tableau 5.3 - Résumé des fonctionnalités de IADP ......................................................................................... 134

Introduction Générale 1

Introduction Générale

Environnement économique turbulent, instable et incertain et de plus en plus compétitif,

globalisation et fragmentation des marchés, réduction du cycle de vie des produits,

extraordinaire prolifération de nouveaux produits, accroissement des exigences des clients

pour obtenir des produits sur mesure et des services de qualité au moindre coût, des

innovations technologiques qui jaillissent et se diffusent à un rythme époustouflant, la valeur

des produits dépend de plus en plus des services et des informations qui leur sont associés,

voilà une énumération non exhaustive des problèmes auxquels les entreprises manufacturières

sont confrontées.

Les entreprises traditionnelles qui fonctionnent avec une administration centralisée et une

structure trop hiérarchisée, ne sont pas adaptées à un environnement qui évolue rapidement et

de manière imprévisible. Pour répondre très vite aux besoins des clients, une grande flexibilité

et une grande capacité d'innovation est nécessaire. Ceci est d'autant plus vrai que les clients ne

se satisfont plus de solutions standards, mais demandent de plus en plus des solutions

adaptées à leurs besoins spécifiques.


Les entreprises doivent à la fois s'organiser et fonctionner différemment, pour cela elles

doivent apprendre à mieux tirer avantage des nouvelles formes d’organisation telles que :

L’Entreprise Virtuelle et l’Ingénierie Simultanée. L’Entreprise Virtuelle est une nouvelle

forme d’organisation en réseau dans laquelle un ensemble d’entreprises juridiquement

indépendantes, unissent leurs ressources et leurs compétences afin de réaliser en commun un

projet en recourant aux Nouvelles Technologies de l’Information et de Communications

(NTIC). L’Ingénierie Simultanée traduit une nouvelle méthode de développement collaboratif

et intégré de produit qui consiste à réaliser les tâches de conception et de fabrication, en

remplaçant la structure séquentielle linéaire par un travail de ces fonctions en parallèle. On

intègre alors les phases d’étude des moyens de fabrication dès la conception du produit, ce qui

permet de compresser les délais de manière significative.

Le problème crucial qui se pose alors est de communiquer entre les différents acteurs afin de

synchroniser leurs efforts pour parvenir à l’aboutissement d’un ou de plusieurs projets

communs. Cette volonté se heurte au fait que chaque acteur utilise des données spécifiques à

son métier et à son expérience. L’échange et le partage de ces données créent des problèmes

considérables au niveau de la capitalisation des connaissances entre les différents partenaires.

C’est dans ce contexte que le projet STEP a été introduit. L’objectif de STEP est de définir

une représentation non ambiguë des données de produit tout au long de son cycle de vie,

interprétable par tout système informatique, en vue d’un échange facile et fiable entre les

différents intervenants. Pour cela, STEP propose des langages, des modèles de données ainsi

qu’une méthodologie pour développer ces modèles de données.

Or, Il est vite apparu que la prise en compte des points de vue des acteurs intervenant dans un

projet est indispensable pour une modélisation complète et efficace de produits. En effet les

acteurs travaillant simultanément au projet sont nombreux et de spécialités très différentes

(Client, Commercial, Concepteurs, Fabricant, etc.). Les points de vue qu’ils portent sur le

produit sont également très différents.

Malheureusement, les modèles STEP ne permettent pas aux acteurs participant au

développement du produit d’exprimer leurs points de vue, alors que la notion de point de vue


est fondamentale pour une conception collaborative et intégrée. Signalons également que les

modèles de STEP sont statiques et ne fournissent qu’une représentation partielle du produit,

ils n’assurent que la structure et la géométrie et le lien avec la fabrication reste incomplet. Il

s’agit aussi du manque de modèles d’expression des besoins suffisamment compréhensibles

pour assurer une communication efficace et non ambiguë entre les acteurs concernés, et qui ne

fait pas ralentir le développement des produits à cause des multiples itérations nécessaires

pour préciser les besoins et valider les spécifications.

Des travaux d’extensions des modèles de STEP existent mais présentent comme inconvénient

de n’être guidés par aucune méthodologie au niveau de la structuration des informations

contenues dans les modèles ce qui provoque des erreurs de sémantique importantes. La même

remarque peut être également faite sur la construction des modèles initiaux eux-mêmes.

A toutes ces constatations se rajoute un problème lié aux outils informatiques support à la

capitalisation des connaissances et d’informations entre les membres d’une Entreprise

Virtuelle. En effet, le système d’information actuel de l’Entreprise Virtuelle se préoccupe

encore peu de la capitalisation des connaissances entre les partenaires impliqués dans un

projet. Les informations sont essentiellement véhiculées par téléphone ou messagerie

électronique, ce qui ne facilite pas l’accès rapide à l’information pertinente et à jour. Se pose

également le problème de mise à jour des documents suite à des modifications et engendre

des problèmes de prise en compte de ces modifications par les acteurs concernés. A tous ces

problèmes se rajoute le manque d’outils d’aide à la modélisation STEP. Il est donc nécessaire

de définir une infrastructure support à l’Entreprise Virtuelle, ou les informations puissent être

modélisées, stockées, partagées, centralisées, analysées et mises à jour.

C’est sur ces hypothèses que se base la définition de notre problématique et le travail réalisé.

Ainsi le travail de thèse présenté dans ce mémoire a pour objectif de mettre en place un cadre

méthodologique pour enrichir les modèles de STEP et de mettre en place une infrastructure

informatique pour le stockage et le partage des informations entre les membres de l’Entreprise

Virtuelle.


Ce manuscrit est constitué de deux parties :

La première partie est constituée de trois chapitres : le chapitre 1 définit le contexte

économique et organisationnel dans lequel se situe ce travail de thèse. Il présente l’évolution

des marchés et de l’environnement, ainsi que les profondes transformations que ces

évolutions impliquent pour l’organisation des entreprises, avec les concepts d’Entreprise

Virtuelle et d’Ingénierie Simultanée. Le chapitre 2 traite les problèmes de communication de

données entre les différents partenaires. Il présente les travaux effectués dans le domaine de

l’échange, partage et l’intégration de données. Il conduit à formuler les difficultés rencontrées

dans le développement collaboratif de produit. Un accent particulier est mis sur la norme

STEP. Ceci permet de préciser dans le chapitre 3, la problématique de notre travail de thèse

et d’éclaircir le cahier des charges du travail proposé. Une étude des approches susceptibles

de réaliser le cahier des charges ainsi posé permet par ailleurs de déterminer les éléments clés

sur lesquels se base le cadre méthodologique proposé. Il introduit les deux autres chapitres du

manuscrit, relatifs à nos contributions.

La deuxième partie du manuscrit décrit notre apport personnel. Elle est constituée de deux

chapitres : le chapitre 4 présente la méthodologie proposée pour la représentation des points

de vue des acteurs de la conception et de la fabrication. Cette méthodologie est développée

selon deux axes : l’axe Produit et l’axe Processus, regroupant respectivement les

informations et points de vue métier sur le produit ainsi que son processus de fabrication. Le

chapitre 5 présente l’infrastructure informatique support à la méthodologie proposée.

Nous terminerons ce mémoire avec une conclusion qui reprend les grandes lignes de cette

étude et la contribution de l’approche proposée. Elle montre également les diverses

prolongations possibles de ce travail.

Première Partie

Etat de l’Art et Approche proposée

Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 5

Chapitre 1

L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation

1. Introduction

Pour répondre aux forces de l’environnement et aux défis qui en découlent pour les

organisations, une grande flexibilité et une grande capacité d’innovations sont nécessaire, ce

qui les amène à remettre en question certains processus et modes de fonctionnement. Elles ont

ainsi de plus en plus recours à certaines pratiques exemplaires (Best Practises), nous pouvons

en citer deux, ce sont : L’Entreprise Virtuelle et l’Ingénierie Simultanée.

Dans ce premier chapitre, nous allons dans un premier temps analyser l’évolution des marchés

et de l’environnement. Nous pourrons alors dans un second temps, présenter les nouvelles

formes d’organisation de l’entreprise à savoir l’Entreprise Virtuelle et l’Ingénierie

Simultanée. Enfin, nous présenterons quelques outils informatiques de leur mise en œuvre.


2. Les forces de l’environnement

A l’origine de la transformation des organisations, il y a des forces qui affectent toutes les

entreprises, où qu'elles soient dans le monde et quel que soit le secteur où elles se trouvent.

Peu importe ce que font les individus, les entreprises et les gouvernements, ces forces

changent l’environnement dans lequel évoluent et devront évoluer les entreprises au cours

des prochaines décennies. Elles sont à l’origine de la complexité croissante des choix

stratégique s’offrant aux entreprises. Ces dernières doivent alors s’efforcer de trouver des

réponses adaptées aux besoins spécifiques de chaque client. Nous avons regroupé ces forces

sous les quatre thèmes suivants :

• exigences accrues des consommateurs,

• globalisation des marchés,

• concurrence accrue axée sur la productivité et la qualité,

• accélération du développement et de la diffusion de la technologie.

2.1 Exigences accrues des consommateurs

Les consommateurs, plus éduqués et mieux renseignés, ont à leur disposition plusieurs

moyens pour comparer la qualité des produits qui leur sont offerts. La compétition entre les

entreprises les amène à offrir des solutions de plus en plus intéressantes pour les utilisateurs.

Une vaste enquête américaine sur les enjeux dans le secteur manufacturier, The Next

Generation Manufacturing Project – NGM1 [NGM97], a défini ainsi les exigences accrues

des consommateurs :

• recherche d’une satisfaction globale procurée par le produit,

• délais de livraison plus courts,

• coût le plus bas possible,

• plus grande qualité,

1 Ce projet a été coordonné par l’Agility Forum, les Leaders for Manufacturing du MIT et le Technologies Enabling Manufacturing Program. Il a pu compter sur les efforts de plus de 500 gestionnaires et spécialistes d’une centaine de compagnies et de plusieurs centres de recherche et universités.


• plus grande variété de produits,

• produits faits sur mesure pour des besoins spécifiques.

La capacité de satisfaire le consommateur devient l’enjeu principal de la concurrence, plutôt

que la maîtrise de la technologie. Celle-ci doit être subordonnée à la première. On passe d’une

économie «poussée par la technologie » à une économie «tirée par le consommateur ».

Les consommateurs doivent alors être intégrés à la chaîne d’approvisionnement qui part des

matières premières et qui remonte jusqu’à eux.

Les entreprises doivent donc développer leur capacité de répondre rapidement aux besoins des

consommateurs. Selon le NGM, on peut opposer les changements dans cette capacité de

répondre aux exigences des consommateurs selon les cinq dimensions suivantes :

Maintenant Prochaine génération

Solutions ponctuelles Solutions intégrées

Livrer ce qui est commandé Livrer ce qui est nécessaire

Rencontrer les exigences actuelles Anticiper des exigences qui évoluent

Revenu découlant d’une transaction Revenu sur tout un cycle de vie

Satisfaction des clients Satisfaction de tous les intéressés

Un fabricant ne doit donc plus uniquement vendre un produit, mais il doit satisfaire les

besoins des consommateurs. Pour vraiment anticiper l’évolution de ces besoins, le fabricant

doit établir une relation suivie, un partenariat avec ses clients. Le recours aux prévisions de

vente doit être remplacé par une interaction et une planification continues. Cette vision

change évidemment la façon de concevoir les produits dans l’avenir, mais également les

méthodes de production et les organisations. En contrepartie de l’implication des clients dans

ces processus, l’entreprise espère créer une plus grande fidélité de la part de ses clients.

L’objectif est alors de permettre une plus grande connivence entre les clients, les

propriétaires, les employés de l’entreprise, de même qu’avec leur milieu.


Dans un rapport sur l’évolution des secteurs manufacturiers, Deloite & Touche [DEL98]

explique l’évolution actuelle de passage à l’ère du consommateur virtuel, qui suit l’ère de

l’assemblage de masse, qui a dominé jusqu’aux années 70, et l’ère de la qualité, des années

80. Les consommateurs autour du monde décident quoi, quand, où et comment ils vont

acheter et consommer les produits et services. Ils peuvent s’informer dans le cyberspace2,

mais en plus, ils commencent de plus en plus à exercer leur pouvoir en utilisant ces nouveaux

moyens. De plus, leurs exigences non seulement n’ont pas fini de croître mais elles

deviendront de plus en plus difficiles à prévoir. Tout cela implique évidemment la nécessité

absolue de mieux coordonner les ventes et le marketing avec la production. Cela suppose que

les entreprises devront établir un partenariat avec leurs clients au niveau de la R&D, du

marketing et de la fabrication. Il s’agit là de la seule façon d’évoluer avec son marché et de ne

pas être pris au dépourvu par son évolution. Les entreprises doivent donc devenir des

organisations centrées sur les clients ( customer-centric organization)3.

2.2 Globalisation des marchés

Malgré le caractère distinct de marchés régionaux, on assiste à la globalisation des marchés.

Cette mondialisation, on peut la situer à cinq niveaux. Il y a d’abord une mondialisation

commerciale qui fait en sorte que les produits et services peuvent circuler de plus en plus

librement entre les pays, sans tarifs douaniers ou autres mesures non-tarifaire. Il y a ensuite

une mondialisation de la production telle que la fabrication peut utiliser des sous-ensembles et

des composants provenant de n’importe quel endroit dans le monde. Des barrières

géographiquement qui limitent ces déplacements demeurent, mais les possibilités

d’approvisionnement sont examinées à une échelle planétaire. Par ailleurs, la possibilité de

délocalisation pour profiter de conditions plus intéressantes fait partie des réflexions

stratégiques des grands groupes industriels et de la distribution.

Au troisième niveau on retrouve une mondialisation technologique qui se manifeste par une

diffusion instantanée de la technologie dans tous les pays, du moins dans ceux qui sont

capables d’absorber les nouvelles technologies et qui possèdent une infrastructure de base

2 Cyberspace : Mot inventé par William Gibson (en 1984) pour désigner l'univers virtuel, régi par les nouvelles technologies, qui s'étend au-delà de l'ordinateur, dans les réseaux de communication (Internet). 3 Organisation plaçant le client au cœur de ces préoccupations.


minimale. Le nombre de pays possédant ces caractéristiques est en fait en perpétuelle

croissance et le nombre de concurrents potentiels n’a cessé d’augmenter au cours des

dernières années. Il y a ensuite une mondialisation financière, comme on peut le constater

avec les nombreuses prises de contrôle et participations croisées dans plusieurs secteurs.

Les mégafusions et les grandes alliances ce doublent en effet souvent de mouvements de

capitaux internationaux importants. Il y a finalement une mondialisation de la consommation

qui fait en sorte que les modèles de consommation deviennent de plus en plus planétaires. On

le constate dans le monde de l’automobile avec la convergence des modèles sur les différents

marché régionaux vers la voiture mondiale (world car), alors qu’auparavant chacun de ces

marchés avait ses propres modèles.

Le rapport du NGM fait une comparaison entre la façon de répondre à cette globalisation du

marché et la façon dont devront fonctionner les entreprises de la prochaine génération.

Maintenant Prochaine génération

Marketing international Ensemble des opérations mondialisées

R&D dans le pays d’origine R&D dispersée

Part de marché par pays Part du marché mondial

Firme étrangère avec des investissements

étrangers

Perçue comme une firme locale dans chaque

marché

Plusieurs compagnies ont des opérations internationales depuis longtemps, mais il s’agit

maintenant de devenir une véritable compagnie mondiale qui prend des décisions en fonction

de sa part de marché pour l’ensemble de la planète. En même temps, elle doit bien

comprendre chacun des marchés locaux de façon à rester le plus près possible de ceux-ci.

Mais, il ne faut pas non plus se limiter aux aspects ventes et développement de nouveaux

marchés. L’étude de Deloite & Touche [DEL98] fait ressortir que les grandes compagnies

manufacturières américaines ont développé de grandes capacités pour vendre et distribuer

leurs produits sur les marchés internationaux, mais qu’elles ont beaucoup plus de faiblesses en

ce qui concerne la mondialisation de leurs activités de R&D et de production.


2.3 Concurrence axée sur la productivité et la qualité

La production de masse a atteint son zenith dans les années 50 et 60, pour décliner par la

suite. Face à ce déclin, qui se traduisait par une érosion de leur part de marché, les grandes

entreprises, en particulier aux Etats-Unis, ont réagi énergiquement avec une variété

d’approches. Dans les années 70 et 80, ces firmes ont développé des programmes

d’amélioration des conditions de vie au travail, des systèmes de planification des ressources et

de la production (MRPI et II), des approches qui permettaient d’éliminer les coûts directs de

main d’œuvre par le biais de l’automatisation. Ces projets étaient surtout orientés pour

répondre à la compétition. Toutefois les succès n’ont pas toujours été à la hauteur, ce qui a

amené certaines d’entre elles à prendre conscience que leurs difficultés pouvaient être

attribuées à leur inhabilité à se libérer de paradigmes non adaptés au nouvel environnement,

en particulier celui de la production de masse. La clé de la réussite est désormais d’emprunter

la voie de la flexibilité et de l’agilité d’où l’émergence de nouveaux paradigmes de production

telles que la production au plus juste (lean production), l’amélioration kaizen4, la réingénierie

des processus5 d’affaires et la gestion de la qualité totale, et plus récemment, la production

flexible, la personnalisation de masse, la production agile.

Parallèlement, le concept de qualité totale s’est également imposé et il est devenu une norme

incontournable. Pendant très longtemps, les entreprises se sont attachées à produire des

produits de qualité, aujourd’hui, cela ne suffit plus et les entreprises performantes construisent

leur compétitivité sur le concept de la qualité totale qui va de l’accueil du client, à la

responsabilisation de tous les employés et à la conception de produits de qualité. C’est donc

une véritable philosophie, une nouvelle démarche qui suppose un changement de culture dans

les organisations. La recherche de la qualité totale est une démarche à petits pas

d’amélioration permanente à tous les niveaux de l’organisation et dans tous les domaines.

Depuis les travaux du Womack sur la production au plus juste (lean production) [WOM90],

plusieurs firmes sont devenues en fait conscientes du fait que sans gestion de la qualité totale,

elles sont dans l’incapacité de rattraper la compétition internationale croissante. Le succès

4 méthode de management, d'origine japonaise, impliquant tous les acteurs de l'entreprise dans une recherche quotidienne d'efficacité. 5 Traduction de :Business Process Reengineering.


d’une firme dépend maintenant de sa capacité d’offrir des produits ou des services de qualité

qui seront perçues comme les « meilleurs » aux yeux des consommateurs. Ce « meilleur » ne

réfère pas à la qualité globale dans le sens moderne du mot, mais dépend des exigences et des

perceptions des consommateurs. En réalité cela inclut l’utilité du produit, la sécurité qu’il

offre, la satisfaction que procure un fonctionnement sûr, durable, facile à réparer, sans oublier

la valeur esthétique, le prestige et le statut que le produit procure. La gestion de la qualité

totale est aussi une philosophie que la haute direction doit adopter et afficher avec conviction.

La qualité totale n’est à cet égard possible à réaliser que si chaque employé fournit l’effort de

contribuer à la qualité totale de la firme.

Cette façon de voir s’est inspirée de l’approche japonaise du Kaizen. Ainsi, d’après Toyota

[TOY98], le Kaizen fournit le dynamisme nécessaire à l’amélioration continue, la motivation

pour les individus d’investir dans la conception et la gestion de leur propre travail et concourt

à maximiser la productivité dans chaque site de travail. Les activités kaizen incluent des

mesures pour l’amélioration de l’équipement, aussi bien que pour l’amélioration des

procédures de travail. Toujours, concernant l’approche japonaise kaizen, Masaaki [MAS89]

ajoute que l’amélioration de la qualité et de la productivité qui se fait dans le cadre du kaizen

mène à des réductions de coût, ce qui ne présente pas une contradiction. Les résultats de

l’étude du Womack [WOM96] démontrent que la réalisation simultanée de ces objectifs

(qualité/productivité) est un facteur clé de succès dans l’industrie automobile et dans d’autres

secteurs.

Il apparaît donc clairement que les entreprises, dans le cadre des exigences de leur

environnement et pour répondre efficacement aux désirs des consommateurs, doivent

maîtriser leur gestion de la qualité totale, tout en assurant à leurs clients la garantie et

l’assurance d’une amélioration continue à ce niveau. Il s’agit d’une exigence de base à

laquelle tous sont confrontés.

2.4 Accélération du développement et de la diffusion de la technologie

les nouvelles technologies de l’information et de la communication ont amené une véritable

explosion de l’information disponible. Les infrastructures en place permettent de connaître ce

qui se passe partout sur la planète, via l’Internet en particulier, en même temps qu’elles


permettent aux entreprises de communiquer avec leurs fournisseurs, leurs partenaires et leurs

clients via des Extranets6.

Cette explosion de l’information disponible amène un déplacement des avantages

concurrentiels qui se situent de moins au moins au niveau de la possession de cette

information, mais de plus en plus au niveau de la capacité de traiter cette information et de

prendre des actions stratégiques à partir de celle-ci.

L’abondance de l’information disponible est certainement un stimulant au développement des

connaissances et à l’innovation, tant au niveau des produits et services qu’au niveau des

processus et des organisations. Contrairement à ce que l’on observait il y a quelques années à

peine, la technologie est maintenant disponible en grande quantité et à un prix de plus en plus

abordable. Si on veut parler de pénurie, c’est plutôt du côté des techniciens spécialisés qu’il

faudrait regarder, à cause justement de l’abondance des innovations technologiques qui

rendent de plus en plus difficile la mise à niveau des ressources humaines dans l’entreprise.

Le rapport NGM parle d’ailleurs d’un rythme d’obsolescence des connaissances de l’ordre de

20% par année. Du fait que les développements de la technologie deviennent de plus en plus

universellement disponibles, l’avantage concurrentiel d’une entreprise ne peut donc plus

reposer uniquement sur sa supériorité technologique. Cette accessibilité représente une

opportunité, celle de trouver des partenaires ayant des compétences complémentaires à celle

de l’entreprise, à n’importe quel endroit dans le monde. Par contre, la possibilité que l’avance

technologique de l’entreprise soit remise en question rapidement amène le risque que certains

investissements ne puissent être rentabilisés avant leur mise au rancart. On peut appliquer le

même raisonnement au niveau des travailleurs spécialisés, dont les connaissances ont une

durée de vie de plus en plus courte.

6 Réseau de télécommunication et de téléinformatique constitué d'un intranet étendu pour permettre la communication avec certains organismes extérieurs, par exemple des clients ou des fournisseurs.


3. Les pratiques émergentes

L’ensemble des forces en action dans l’environnement impliquent de nouvelles exigences

pour les entreprises. Le NGM identifie six attributs des entreprises manufacturières de

l’avenir dans son rapport :

• capacité de répondre au consommateur,

• capacité de réponse des équipements et des usines,

• capacité de réponse des ressources humaines,

• capacité de répondre au marché global,

• le travail en équipe est la première des compétences,

• développement d’une culture et de pratiques permettant de répondre et d’anticiper les

changements.

En fonction de ces défis que nous venons d’énumérer, certaines pratiques exemplaires7 se

sont développées afin de leur répondre. Nous pouvons en citer deux, ce sont : L’Entreprise

Virtuelle et l’Ingénierie Simultanée.

3.1 L’Entreprise Virtuelle

3.1.1 Caractéristiques fondamentales

Pour Probst [PRO96], l’Entreprise Virtuelle est un réseau, plus au moins temporaire,

d’entreprises juridiquement indépendantes ou de personnes qui unissent leurs moyens, leurs

compétences et autres ressources, afin de réaliser en commun un projet pouvant dépasser les

capacités de chaque unité considérée séparément. L’Entreprise Virtuelle cherche à exploiter

des opportunités volatiles, à accéder à de nouveaux marchés et à partager les coûts et les

risques, ceci sans superstructure organisationnelle importante, en recourant aux nouvelles

possibilités des technologies de l’information et de la communication. Perlo et Hills [PER98]

ajoutent que l’entreprise virtuelle se caractérise par des équipes qui ne sont pas seulement

7 Connu sous le vocable de Best Practises.


multisites et éparpillés dans les différentes parties du globe, mais qui sont aussi multilingues,

multiculturelles, multifonctions, et multimétiers.

Le concept d'Entreprise Virtuelle, dans le sens d'alliances stratégiques, n'est pas nouveau. Des

structures basées sur des alliances stratégiques ou opportunistes, existent depuis longtemps

dans des secteurs tels que l'horlogerie et la construction [MAI90]. Toutefois, ce n'est que

récemment, depuis l'intégration des technologies de l'information et de communication, que

des compagnies indépendantes peuvent former de véritables entreprises virtuelles exploitant

les meilleures compétences disponibles dans le monde.

Une telle organisation implique des relations de confiance et une compréhension mutuelle de

la manière de traiter les affaires. En effet, il est hors de question de pouvoir conclure des

contrats couvrant tous les problèmes imaginables. De plus, la réussite du projet nécessite

souvent de partager sans restriction des informations confidentielles.

Comme le soulignent Chesbourgh et Teece [CHE96], plus le projet commun est complexe,

plus il est nécessaire qu'une des unités joue un rôle pivot d'intégrateur et de coordinateur. Une

entreprise virtuelle internationale étant constituée d'entreprises indépendantes, un des défis à

relever est de faire collaborer des personnes de cultures différentes (nationalité, milieu

professionnel, langue, etc.) qui travaillent dans des sites géographiquement dispersés, selon

des procédures différentes, à l'aide de supports informatiques hétérogènes (type de réseau, de

système d'exploitation, bases de données, applicatifs).

L'émergence d'entreprises virtuelles ne va pas seulement changer la manière de traiter les

affaires, mais elle va profondément modifier la structure des entreprises participantes. En se

liant dans une entreprise virtuelle, chaque unité peut se concentrer sur ce qui constitue ses

compétences spécifiques. Cette concentration sur les "core competences" comme illustré dans

la figure 1.1 est aujourd'hui considérée comme une nécessité.


A4 B1 C3 D4 E2

A1 B1 C1 D1 E1

A4 B4 C4 D4 E4

A2 B2 C2 D2 E2

A3 B3 C3 D3 E3

A4

B1

C1

D4C3

E2D2

ENTREPRISEVIRTUELLE

CORE COMPETENCES :

Ai, Bi, Ci, Di, Ei,...

PROCESSUS DE SERVICE DEL'ENTREPRISE i

Figure 1.1 - Illustration schématique d'une Entreprise Virtuelle

L’Entreprise Virtuelle, selon Luik [LUI96], a quatre caractéristiques principales :

• Les sociétés virtuelles sont dynamiques et elles peuvent réagir rapidement face à

l’évolution du marché.

• Elles ont un caractère éphémère, bien que certaines aient duré jusqu’à huit ou neuf

ans, bon nombre n’existent que pendant quelques mois.

• Les sociétés virtuelles ont une hiérarchie vaguement définie et s’en soucient très peu,

ce qui est en partie attribuable au fait qu’une hiérarchie n’est pas nécessaire dans une

organisation éphémère. Dans la société virtuelle, c’est la nature des relations, plutôt

que les liens hiérarchiques officiels qui détermine le succès de la société. Dans ce type

d’entreprise les relations sont des relations de confiance.

• Les compétences de base dans une société virtuelle sont reparties entre tout le groupe

ou le consortium de groupes.

Luik [LUI96] a aussi énuméré certaines des raisons qui expliquent que des organisations

choisissent cette voie :


• Les clients. Les clients se retrouvent maintenant au centre de l’action dans la plupart

des entreprises. Leurs demandes sont extrêmement changeantes et volatiles, ce qui

favorise un facteur sous-jacent de la société virtuelle, la rapidité.

• La répartition des coûts et des risques. La société virtuelle peut répartir à la fois les

coûts et les risques entre plusieurs entreprises intervenants, dont certaines sont plus

avancées et donc mieux en mesure de supporter le risque.

• Les compétences de base. Les compétences de base ont quelque chose de paradoxal.

D’une part on conseille à des entreprises de toutes tailles de réduire le nombre de

compétences de base qui les définissent. D’autre part, les entreprises constatent que

pour répondre aux besoins de leurs clients, il leur faudra peut-être acquérir d’autres

compétences de base. L’Entreprise Virtuelle semble offrir le moyen idéal d’éviter ce

paradoxe. Elle permet à un consortium d’entreprises, chacune ayant des compétences

de base assez distinctives, de se réunir et d’offrir une gamme complète de

compétences de base.

• Le capital intellectuel. Les sociétés virtuelles règlent le problème essentiel du capital

intellectuel. S’il y a une seule ressource qu’il faut gérer adroitement dans une

entreprise virtuelle et qui oblige les sociétés à envisager l’adhésion au monde virtuel,

c’est bien le capital intellectuel.

• La maîtrise du changement, de l’incertitude, et de la complexité. Les entreprises

virtuelles procurent une structure grâce à laquelle on peut maîtriser le changement,

l’incertitude et la complexité. En réalité cela ne veut pas dire que ces entreprises sont

mesure de fournir des réponses complètes et simples à ces problèmes très complexes,

mais plutôt que les personnes qui œuvrent au sein de ces entreprises sont orientées en

fonction de ces défis que représentent le changement, l’incertitude et l’imprévisibilité.

Il faut cependant souligner que le travail au sein d’équipes virtuelles exige aussi une souplesse

étonnante de la part des membres de l’équipe et le respect des différences entre ces membres

(culture, langue, style de travail etc.). Non seulement travaillent-ils avec quatre ou cinq

équipes de projet par jour, mais leur rôle change également, car ils dirigent au sein d’une

équipe et ont un rôle de soutient au sein de l’autre. En effet, une telle organisation implique,

selon Probst [PRO96], des relations de confiance et une compréhension mutuelle de la


manière de traiter des affaires, un grand partage sans restriction des informations

confidentielles, et surtout la motivation de chaque membre de l’équipe. Il est aussi évident

que le management traditionnel perd toute son efficacité dans ce type particulier d’entreprise

et que le management « à distance » ou « virtuel » impose aux gestionnaires des changements

radicaux dans leur façon de travailler et une maîtrise parfaite de nouvelles compétences.

3.1.2. Types de L’Entreprise Virtuelle

Il existe trois types d’Entreprise Virtuelle (E.V): 1) E.V court-terme, 2) E.V Consortium, 3)

Entreprise Etendue. Le point de départ est une E.V court-terme dans un marché opportuniste.

Avec la stabilisation du partenariat, cette E.V migre progressivement vers une E.V de type

Consortium (marché dynamique). Une E.V (soit court-terme ou soit de type Consortium) peut

avoir une durée de vie plus longue si ces membres forgent ensemble leurs qualités pour faire

face à une opportunité du marché qui grandit. Dans ce cas, l’E.V. migre encore vers une E.V

de type Etendue en stabilisant sa structure.

Cependant, beaucoup confondent la notion d’Entreprise Virtuelle avec celle d’Entreprise

Etendue. Toutes deux sont inter-organisationnelles, exigeant partenariat et organisation en

réseaux, mais la différence entre Entreprise Etendue et Entreprise Virtuelle réside dans

l’aspect temporaire de cette dernière.

Il faut garder à l’esprit qu’une Entreprise Virtuelle est éphémère. Elle n’est que momentanée

et de durée limitée. Une Entreprise Virtuelle est un regroupement temporaire et flexible tandis

qu’une Entreprise Etendue exige plus de stabilité.

3.2 L’Ingénierie Simultanée

3.2.1 L’approche linéaire et son abandon

Lors de la création d’un produit, la plupart des entreprises manufacturières appliquent encore

une démarche linéaire. Cette démarche a été imposée par le développement d’organisation de

l’entreprise et le flux d’information entre différents services.


Afin de franchir les étapes du cycle de vie du produit, un grand nombre de personnes vont

intervenir successivement : les hommes de marketing qui définissent le cahier des charges,

l’ingénieur d’étude qui va bâtir une solution technique, le dessinateur qui va le représenter, le

designer qui va définir des formes agréables à l’œil, l’ingénieur de calcul qui va dimensionner

les éléments garantissant un certain comportement en service ou une durée de vie du produit,

l’ingénieur des méthodes qui va choisir les procédés d’obtention et étudier les gammes de

fabrication, les hommes de l’atelier qui vont réaliser le produit, l’équipe des essais qui

acceptera ou refusera le produit après vérification de son adéquation du cahier des charges,

l’agent de vente qui va commercialiser le produit et enfin l’équipe de maintenance qui va

suivre le produit en service.

Cette vision traditionnelle, héritée du taylorisme, est généralement qualifiée de séquentielle,

compte tenu de l’enclenchement chronologique des activités. Elle a le mérite de définir un

ordre nécessaire dans la maîtrise du cycle de vie du produit et de ses processus et ainsi

d’établir des responsabilités claires. Mais, la division du travail entre différents services et

aussi à l’intérieur de ceux-ci détermine une spécialisation étroite du personnel et le

regroupement selon le critère de tâches à accomplir. Ainsi, chaque groupe s’enferme dans sa

propre idée sur le produit, dans leur culture et leur langage de communication. En effet, le

marketing n’a pas la même vision du produit que les gens des méthodes, de l’atelier ou de

maintenance.

Dans l’activité quotidienne de l’entreprise et dans ces conditions, on observe assez souvent de

nombreux dysfonctionnement :

• Le produit obtenu en terme du processus de conception est souvent remis en cause à

tous les niveaux parce qu’il fonctionne imparfaitement ou ne satisfait pas

complètement ses utilisateurs,

• Sous la pression des délais imposés ensuite, l’étude est trop souvent limitée au

développement de la première idée envisagée, négligeant ainsi des solutions qui

auraient pu s’avérer plus satisfaisantes,

• Le personnel d’étude est amené à effectuer de nombreux choix et à prendre de

nombreuses décisions sur des questions ne relevant pas nécessairement de leur


compétence directe, cela limite fortement la liberté de manœuvre des services qui

interviennent par la suite,

• Le service des méthodes, chargé de la conception des processus et moyens de

productions est très souvent amené à demander des modifications au Bureau d’Etudes,

qui sont très rarement acceptées, leurs répercussions étant jugées trop importantes, car

elles interviennent tardivement,

• La nature séquentielle de l’organisation détermine l’apparition de bouclages de

correction qui s’avère être assez rarement efficaces, influençant les délais et les coûts.

De toutes ces constatations on ne peut dégager qu’une seule conclusion : il faut reconsidérer

le cycle de production d’un produit.

3.2.2 L’approche simultanée

Dans la littérature on trouve les concepts d’Ingénierie Simultanée et d’Ingénierie Concourante

[HAA01][STA02]. Ce sont deux traductions de « Concurrent Engineering ». Tentons

maintenant d’avancer à l’aide de quelques définitions :

• L’Ingénierie Simultanée est une méthode de management de projet dont les buts sont

l’amélioration des délais, des coûts, de la qualité, des performances techniques

[BOU94].

• Le concurrent Engineering est une approche organisationnelle systématique tendant

vers la conception simultanée et intégrée des produits et de leurs méthodes et

procédés de fabrication associés ainsi que de la logistique de soutien nécessaire à

l’exploitation de ces produits par leur utilisateur final [JAG93].

En lisant ces définitions, on constate tout d’abord que, fort logiquement, l’Ingénierie

Simultanée est avant tout une réponse aux principales critiques formulées plus haut et vise

donc une amélioration globale de la conception. Regardons donc maintenant comment elle se

propose d’y parvenir. Globalement, l’Ingénierie Simultanée doit permettre une réduction du

temps global du projet par un recouvrement partiel des tâches, ainsi que par la réduction de


chacune des phases, rendue par la suppression des retours en arrière, ce qu’illustre la figure

1.2.

La pluridisciplinarité permet de prendre en compte toutes les contraintes liées à la totalité au

cycle de vie dés le départ, et donc de supprimer les rétroactions. En plus elle permet une

amélioration continue, l’utilisation de méthodes formelles et semi-formelles et l’exploration

rapide de solutions par le prototypage rapide par exemple [HSI02]. Cette dernière technique

permet la fabrication d’un modèle physique (maquette, prototype, outillage) dans un délai très

court, à moindre coût et avec le minimum d’outillage et d’étapes intermédiaires dans le

processus de réalisation [BER96].

Figure 1.2 - Gain de temps apporté par la démarche simultanée

On peut ainsi plus facilement au cours du cycle de développement d’un produit [KOU01] :

• Détecter au plus tôt d’éventuels problèmes de conception, sans conséquences majeures

sur le coût final,


• Tester des solutions alternatives (choix technologique pour la pièce, procédés utilisés

pour sa fabrication, etc.) ,

• Valider rapidement la faisabilité industrielle de la pièce et optimiser les formes et le

coût des outillages futurs nécessaires à sa fabrication en série, et donc minimiser les

risques de modifications lors de la mise en production,

• Affiner les caractéristiques opérationnelles du produit (mécanique, aérodynamiques,

esthétiques, ergonomique, etc.) au travers de tests en grandeur réelle sur un prototype

physique.

En résumé, on peut dire que l’Ingénierie Simultanée est un moyen rapide de développer des

produits prenant en considération l’ensemble des contraintes et spécifications, tout en

intégrant et mettant à profit l’ensemble des savoirs-faire des différents acteurs impliqués.

3.2.3 Outils informatiques de mise en œuvre

Il existe un certain nombre de techniques informatiques qui sont largement et couramment

utilisées pour supporter l'Ingénierie Simultanée dans un contexte d’Entreprise Virtuelle

[KHAa]. Nous vous présentons dans ce qui suit : les Systèmes de Gestion de Données

Techniques (SGDT) et les Progiciels de Gestion Intégrés (ERP)8.

3.2.3.1 Les SGDT

Les Systèmes de Gestion de Données Techniques (SGDT) ou encore (Product Data

Management System) n’ont cessé d’évoluer depuis leur naissance dans las années 80

parallèlement à l’évolution de la technologie et l’accroissement des exigences, passant du rôle

de superviseur des évolutions des plans de CAO, à celui du système d’information global sur

les produits d’entreprise et enfin à celui de système voué à la gestion des données techniques

dans leur totalité.

Les SGDT sont des outils qui aident les ingénieurs à gérer les données et les processus de

développement de produit [MAU95]. Les SGDT conservent, et hiérarchisent toutes les

8 Abréviation de Enterprise Resource Planning


données et informations nécessaires tout le long du cycle de vie d’un produit depuis sa

conception jusqu’à sa destruction voire son recyclage.

Les SGDT apportent à leurs utilisateurs des fonctionnalités permettant de mettre en œuvre

une ingénierie concourante dans un contexte d’Entreprise Virtuelle dans le temps et dans

l’espace. Les SGDT permettent une communication en temps et lieux différents, ce qui leur

permet de capitaliser et de constituer une référence informationnelle ultérieure [RAN95].

Nous récapitulons dans ce qui suit les principales fonctions d’un SGDT :

• Structurer les données : malgré la capacité des entreprises à acquérir ou enregistrer

systématiquement les informations produit (sur différents supports), les informations

pertinentes détenues par certains attributs ne sont pas souvent mises en avant. Ainsi,

pour un composant donné par exemple, il est difficile de retrouver rapidement ses cas

d'emploi ou encore les différents documents qui lui sont associés. Les intervenants sur

le produit ont souvent des difficultés pour accéder à l'information dont ils ont besoin

ce qui réduit l'efficacité de la gestion du produit. Une description des données

techniques par les attributs (d'objets et de liens) et une structuration de ces attributs

offre plusieurs possibilités de tri et de recherche sur les données.

• Classer les données : avec les quantités de données générées, une technique pour

classifier facilement et rapidement ces données est nécessaire. Grâce à la description

des données par les attributs, plusieurs possibilités de classification sont offertes. La

classification concerne essentiellement les composants.

• Visualiser et stocker les données : certaines informations produit sont définies et

archivées dans le SGDT grâce aux classes et attributs associés mais d'autres

informations documentant le produit tels que les fichiers des plans CAO, les fichiers

de photos numérisés, etc. ne sont que référencés. Ceux-ci doivent être alors visualisés

dans le SGDT. Pour certains formats de fichiers, ceci est possible par des "moteurs" de

visualisation9 (Viewer) disponibles dans les SGDT. Pour d'autres formats de fichiers,

ils ne peuvent être visualisés que sur les moteurs qui les ont générés, éventuellement

9 Ce sont des formats d’interprétation pour la représentation alphanumérique ou graphique qui permettent d’archiver la donnée sous son format d’origine.


déportés ou importés dans le SGDT de manière temporaire. Toutefois, certains fichiers

dits "Objets longs" ne peuvent être interprétés, ils sont donc gérés comme un tout dans

une unité informatique qui peut être propre ou non au SGDT. Le SGDT doit alors

assurer l'import - export de ces objets [RAN95].

• Structurer les données entre elles, c'est-à-dire définir les liens entre les différents

objets définis (classes essentiellement). Cela permet entre autres de structurer le

produit en termes de nomenclatures. Ces dernières définissent la décomposition du

produit selon différentes vues du produit pour servir divers acteurs de l'entreprise

(nomenclature fonctionnelle, nomenclature organique d'études, nomenclature

organique de fabrication, nomenclature géométrique, etc.).

• Gérer l'évolution des données : un produit est amené à évoluer durant son cycle de vie

et les données qui lui sont rattachées sont alors évolutives. Pour garder trace des

diverses modifications apportées aux informations produit, différents indices

d'évolution sont affectés à ces informations pour distinguer les diverses versions ou

révisions. Par ailleurs, pour changer d'indice d'évolution, une information produit suit

un processus de modification. Selon l'avancement de ce processus, l'information

modifiée acquit divers statuts (créée, soumise, libérée, validée, etc.).

• Protéger les données, par un contrôle des modifications et des accès. Différentes

autorisations sont définies pour les acteurs ou les groupes d'acteurs. Une autorisation

est un droit pour exécuter certaines fonctions (consulter, créer, modifier) sur les

données selon le statut de ces dernières.

• Distribuer les données, sur tous les sites, à toutes les fonctions. Les bases de données

réparties ne sont pas très courantes, surtout sur des sites distants et hétérogènes. Le

transfert de données créées ou modifiées est parfois automatisé grâce à une notion

"d'abonnement"10 proposée dans certains SGDT.

10 Seules les données qui concernent la liste des produits auxquels chaque site est abonné sont transmises [RAN95].


• Structurer l'instruction d'un dossier et sa chronologie (Workflow) : le workflow

consiste en une représentation graphique d'entités et de relations, de type objet. A

chaque entité est attachée une classe et des attributs : responsables, autorisés, durée de

la tâche, début et fin au plus tôt et au plus tard, description et quantification des

ressources, personnes à prévenir, dispatching, validation, etc. Cette gestion des

procédures porte sur la nature des tâches, leur enchaînement et la surveillance des

délais. Elle nécessite un courrier électronique. Toutefois, il n’y a pas

d'ordonnancement des ressources ou de calcul des chemins critiques, ni de lien

dynamique avec les données manipulés dans ces procédures. Le fait par exemple de

décider de changer de version d'un document à un moment donné du workflow, ne

met pas à jour automatiquement l'objet concerné et ne propage pas l'impact de ce

versionnement sur le reste des données.

3.2.2.2 Les ERP

Dans les années 60, la GPAO (Gestion de Production Assistée par Ordinateur) était utilisée

essentiellement pour déterminer les stocks et les matières nécessaires à la réalisation des

plannings de production et de livraison. Aujourd’hui, on parle d’ERP et ce, pour gérer non

seulement la production, mais aussi les achats, les finances et les études [TOM99]. La figure

1.3 représente les principales fonctions couvertes par un ERP.

G estion A chats etS tocks

G estionFinancière

G estion desR essources H um aines

G estion de laProduction

G estion de laM aintenance

G estion de la Q ualité

E R P

Figure 1.3 - Principales fonction couvertes par un ERP

Comme de nombreuses technologies, l’ERP a d’abord été utilisée par les grandes entreprises,

puis s’est généralisée à des entreprises de taille moyenne lorsqu’elle a été disponible sur des


plates-formes moins onéreuses. Il serait difficile aujourd’hui de s’en passer, non seulement

parce qu’elle contribue à réduire les coûts et les temps de fabrication, mais aussi parce qu’elle

améliore le travail et la collaboration en équipe.

Les outils d’ERP permettent théoriquement de couvrir l'ensemble des besoins fonctionnels de

l'entreprise [LEQ99]. Ils sont caractérisés par une gestion en temps réel, une synchronisation

des traitements des flux physiques, financiers et comptables ainsi que des ressources

humaines et l'exploitation de données cohérentes grâce à des bases de données

multidimensionnelles. Les progiciels ERP sont des systèmes articulés prenant en compte et

transmettant toute information entrée pour une mise à jour immédiate des différents fichiers

concernés.

Les caractéristiques principales du système sont constituées par la modularité, l’intégration, la

paramétrisation et la gestion en temps réel :

• Modularité : Finances, comptabilité, amortissements, planification de la production,

ventes, achats, gestion de projet...

• Intégration : Les modules interagissent et tiennent à jour l’ensemble des flux.

• Paramétrisation : Les éléments susceptibles de varier (taux de taxation, devises

utilisées, prix des matières premières, unités de mesure, etc.) sont stockés sous forme

de tables modifiables, accessibles par tous les modules.

• Gestion en temps réel : Dès qu’un événement survient, l'information est transmise

immédiatement à l’ensemble du système.

4. Conclusion

Dans ce premier chapitre, nous avons étudié le contexte économique et organisationnel dans

lequel se situe notre travail de thèse : le changement des marchés et de l’environnement, ainsi

que l’évolution qu’il induit sur l’organisation des entreprises.


Durant la décennie courante, l’entreprise a su s’adapter aux perpétuels changement de son

environnement et du marché, jusqu’à arriver aux nouvelles organisations que sont l’Entreprise

Virtuelle et l’Ingénierie Simultanée.

L’Entreprise Virtuelle se définit, comme on l’a vu, comme une organisation temporaire

formée à partir d’alliances stratégiques ou de partenariats qui peuvent se dissoudre quand

l’affaire ou le projet sont terminés. Le concept de l’Ingénierie Simultanée traduit une nouvelle

forme de travail pour le développement collaboratif de produit, qui consiste à réaliser les

tâches d’études, de méthodes de fabrication, de logistique de soutien et de distribution, en

remplaçant la structure séquentielle linéaire par un travail de ces fonctions en parallèle, ce qui

permet de compresser les délais de manière significative.

Le problème crucial qui se pose alors est de communiquer entre les différents partenaires afin

de synchroniser leurs efforts pour parvenir à l’aboutissement d’un ou de plusieurs projets

communs. Cette volonté se heurte à l’hétérogénéité des outils informatiques implantés chez

les différents acteurs comme les SGDT. C’est l’objectif du chapitre suivant, d’étudier les

moyens de communications qui puissent rendre transparent pour les différents partenaires

l’échange et le partage des informations, en particulier dans le cadre d’une coopération de

type Entreprise Virtuelle et d’Ingénierie Simultanée.

Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 27

Chapitre 2

Modélisation, échange et partage de données de produit : La technologie STEP

1. Introduction

Le chapitre précédent a mis en lumière l’importance des concepts d’Entreprise Virtuelle et

d’Ingénierie Simultanée pour le développement collaboratif de produit. Ces deux concepts ne

peuvent pas être mis en œuvre que si l’entreprise dispose de capacités de transfert

d’information, en interne comme en externe avec ces partenaires, qui lui permettent d’assurer

que chaque employé dispose toujours de bonne données, au bon endroit et au bon moment.

Or l’hétérogénéité des systèmes informatiques bride fortement ces capacités. Mettre en œuvre

les deux concepts, impose donc, la rationalisation des informations que l’on communique, et

par conséquent la standardisation des modèles de données. C’est dans ce contexte que le

projet STEP a été lancé.

Dans la première partie de ce chapitre, on présente les travaux effectués dans le domaine de

l’échange, partage et l’intégration de données, un accent particulier est mis sur le standard


STEP. Dans la deuxième partie, nous décrivons les concepts fondamentaux de la norme STEP

à savoir : les langages descriptifs, les méthodes de mise en œuvre, les modèles de données et

les tests de conformités.

2. Echange, partage et intégration de données

Pour une meilleure intégration de l'entreprise dans un contexte d'entreprise virtuelle et

d'ingénierie concourante, les entreprises ont dû faire appel à des techniques de communication

entre leurs différentes applications informatiques. Diverses actions, notamment normatives,

ont été menées dans le domaine des échanges, partage et intégration de données techniques

depuis les années 1980.

Les premiers travaux mettent l'accent sur l'échange de données. Ainsi, les premières normes

proposées ciblaient des domaines d'application particuliers telle que la norme allemande

VDA11 pour l'industrie automobile [VDA86], ou des méthodologies particulières telle que la

norme américaine IGES12 [IGE80] créée au départ pour l'échange de données géométriques.

Une version récente d'IGES (5.3) inclut une fonction de modélisation électrique et une

fonction relative au tuyautage, mais celles-ci n'ont pas encore été éprouvées. Par la suite, au

début des années 1990, l'ensemble de ces actions normatives ont été unifiées dans une norme

internationale de l'ISO connue sous le nom de STEP (STandard for Exchange of Product

Model Data). L’objectif était de définir une représentation non ambiguë des données du

produit, interprétable par tout système informatique, et couvrant tout le cycle de vie des

produits. Atteindre cet objectif présentait deux difficultés essentielles :

• la définition d’un format neutre, interprétable par tout système informatique

indépendamment du système particulier utilisé pour générer les données,

11 VDA : Abréviation de Verband der Deutschen Automobilindustrie. 12 IGES : Abréviation de Initial Graphics Exchange Standards.


• la couverture d’un très vaste domaine de connaissance, correspondant à l’ensemble

des catégories de produits (pièces élémentaires, assemblages, mécanismes, etc), et à

tous les métiers (électronique, mécanique, ingénierie,..) ainsi que toutes les phases du

cycle de vie (conception, analyse, fabrication, maintenance, démantèlement). Ceci

imposait de mobiliser, et de faire collaborer, des participants représentant un spectre

extrêmement large de compétences.

La première difficulté a imposé de développer toute une nouvelle méthodologie sur la

modélisation des données pour assurer leur indépendance de tout système. Cette approche

comporte :

• la définition d’un langage formel de spécification des données, le langage EXPRESS,

• la définition de formats neutres d’échanges et de stockage des données décrites dans le

langage EXPRESS.

Ces deux éléments font que les données sont destinées à ne plus dépendre des systèmes qui

les génèrent, mais des modèles qui les décrivent.

La deuxième difficulté a amené à élaborer des procédures permettant de faire collaborer des

spécialistes de chacun des domaines techniques avec des spécialistes de la modélisation des

données pour construire les modèles propres à chaque domaine. Elle a ensuite amené au

développement d’une méthodologie spécifique de modélisation visant à permettre à ces

nombreux groupes d’experts de mettre en commun les modèles relevant des aspects

communs.

Après plus de 15 ans de travaux, au cours desquels plusieurs centaines d’experts appartenant à

19 pays (Australie, Canada, Chine, France, Allemagne, Hongrie, Italie, Japon, Corée du Sud,

Pays-Bas, Norvège, Roumanie, Russie, Suède, Suisse, Royaume-Uni, Etas-Unis) se sont

réunis plus de trois fois par an, une véritable technologie a été développée. Cette norme est

décrite dans les différents fascicules de la norme STEP, officiellement la norme ISO 10303.


Celle-ci qui comporte actuellement environ 110 fascicules soit quelques dizaines de milliers

de pages de spécifications.

La norme STEP a été par ailleurs le moteur de plusieurs travaux de recherche et notamment

des projets européens. Ainsi, associé à l'initiative AIT [AIT93], citons le projet RISESTEP

[RIS98] qui s'intéresse à la spécification et au développement d'une architecture distribuée

pour l'échange et le partage d'information dans un contexte de maquette numérique et le projet

OPAL [OPA96] dont l'objectif est de fournir des concepts pour l'intégration de haut niveau

des processus et de l'information dans le domaine de l'ingénierie et de la production.

Un standard d'échange dédié aux données PDM fut ensuite développé dans la communauté

STEP : il s'agit du PDM Schema développé par PDES Inc. et ProSTEP [PDM99]. PDM

Schema est né d'un effort pour harmoniser les besoins et les modèles de données issus des

protocoles d'application de STEP13 qui couvrent les données PDM (notamment les protocoles

AP203 et AP214) et qui jusqu'alors n'étaient pas interopérables14. L'objectif de PDM schema

est d'offrir un modèle de données unique supportant les données gérées dans les PDM. Ce

modèle devrait permettre aux concepteurs de PDM d'implanter des fonctionnalités PDM en se

basant sur STEP et favoriser ainsi l'interopérabilité des PDM avec d'autres systèmes basées

sur les différents protocoles d'application de STEP. Ce standard fût adopté comme protocole

d'échange dans le projet européen Eurofighter [KER99].

Toutefois, l'échange de données dans STEP n'offrait pas une solution satisfaisante aux

problèmes d'utilisation coopérative d'outils CAO et SGDT, la conversion de données

entraînait une perte d'information à chaque transformation et l'échange était lent entraînant

ainsi des problèmes organisationnels à chaque transfert. Pour pallier à ce problème, un

couplage fort et une intégration plus directe sont nécessaires [LAM00]. Deux nouveaux

standards sont alors apparus pour supporter l'aspect partage dans les scénarios d'intégration de

données produit. Il s'agit des PDM Enablers de l'OMG [OMG98] qui supportent

13 Un protocole d'application est un modèle informationnel dans STEP servant un domaine d'application spécifique. 14 C'est à dire qu'un traducteur d'un protocole donné (AP 203 par exemple) n'est pas capable de lire un fichier produit par un traducteur d'un autre protocole (AP214 par exemple) et vice versa.


l'interopérabilité des systèmes en proposant une architecture d'interfaces standards (API :

Application Programming Interface) aux divers services d'un PDM opérant dans un

environnement distribué. Les PDM Enablers sont en fait des interfaces (API) standards

spécifiés en IDL (Interface Definition Language) qui rendent les services d'un PDM

disponibles pour d'autres systèmes (des systèmes CAO, IAO, FAO et également d'autres

PDM) grâce à un environnement CORBA15 (Common Object Request Broker Architecture).

En se basant sur le modèle CORBA, les systèmes du type XAO peuvent utiliser les interfaces

standards des PDM Enablers pour interagir directement avec tout PDM conforme.

Actuellement, les PDM Enablers fournissent des interfaces directes pour spécifier la gestion

des documents, la gestion des nomenclatures, la gestion des modifications et la configuration

de produits (options et variantes du produit) et également l'import et l'export de fichiers

d'échange STEP.

Actuellement, de nombreux travaux de recherche visent à offrir un cadre de référence pour

l'échange de données, en utilisant les différentes techniques et standards d'échange et de

partage de données proposées. Nous citons en particulier le projet TIMS (Testability of

Interaction-Driven Manufacturing Systems) [MOR00] initié par le NIST (National Institute of

Standards and Technology) dont l'objectif est de rapprocher les deux normes PDM Enablers

de l'OMG et le PDM Schema, en établissant une correspondance entre ces deux standards.

Nous citons également le projet européen Brite-Euram SAVE (STEP in A Virtual Enterprise)

[BOD00] dont l'objectif est de fournir un modèle informationnel supportant l'entreprise

virtuelle, basé sur les résultats issus essentiellement des deux travaux normatifs PDM Schema

et PDM Enablers et des projets RISESTEP et AIT-IP [AIT97]. Ce dernier spécifie et implante

une plate-forme d'intégration. Le projet Esprit EP 20408 - VEGA (Virtual Enterprises using

Groupware tools and distributed Architectures) s'intéresse à l'intégration de STEP avec des

modèles d'information, de CORBA avec une couche intermédiaire (middleware) fondée sur

un courtier d'objets ORB (Object request Broker) et de standards du WEB comme VRML

15 CORBA est une architecture proposée par l'OMG (Object Management Group), déployant les principes fondamentaux pour définir et gérer les interfaces de systèmes distribués. Elle fut le raffinement d'une première architecture proposée par l'OMG : l'Object Management Architecture (OMA). Ces architectures définissent les interactions entre composants d'un système distribué en terme d'invocation sur les opérations des objets encapsulés dans ces composants.


(Virtual Reality Modelling Language) pour la définition et le partage d'informations 3D à

travers l'Internet et dans le cadre d'applications de réalité virtuelle [ZAR98].

D'autres projets s'intéressent aux échanges de types particuliers de données produit, tels que le

projet MERCI (Management, Exchange, and Representation of Component Information)

[WIK00] pour la gestion de données de composants, basé sur la technologie XML16 et le

schéma EXPRESS de STEP.

Dans la suite nous vous détaillons la structure de la norme STEP.

3. Les différents aspects de la technologie STEP

La figure 2.1 présente les différents parties de la technologie développée, qui correspondent

également à la classification des différents fascicules publiés ou encore en travaux.

Figure 2.1 - Structure de la norme STEP

Nous détaillons ci-après le contenu de chacune de ces parties.

16 XML : Abréviation de eXtensible Markup Language. Norme d'échange de documents informatisés issue de SGML, grâce au travail de l'ERB (Editorial Review Board).

Méthodes de Description de l’information

Méthodes de Mise en Œuvre

Tests de Conformités

1

2

4

3

Modèles de Données

Ressources intégrées

Protocoles d’Applications

Application Interpreted Constructs


3.1 Méthodes de description de l’information : le langage EXPRESS

Le travail sur le développement des modèles STEP a commencé en 1986. Aucune notation de

modélisation des données ne s’avérant à la fois suffisamment précise et suffisamment

expressive [SCH94] un nouveau langage a dû être développé.

3.1.1 Origine

EXPRESS [ISO94a] est le langage de modélisation des données conçu dans le cadre du projet

STEP. Son objectif principal est la description de modèles d’information dans le domaine

technique, en vue de l’échange de données représentant de façon fiable et non ambiguë ces

informations [BOUb95] [BOUa95]. Dans le langage EXPRESS, l’accent principal est mis sur

la précision du modèle et tout particulièrement sur les contraintes que doivent respecter les

données pour être acceptées comme conforme au modèle, ceci pour assurer la fiabilité de

l’information représentée. EXPRESS n’est pas seulement une notation permettant la

modélisation des données, c'est-à-dire une représentation simplifiée, éventuellement

partiellement ambiguë, des informations propres à un domaine a fins d’échange entre

concepteurs humains pour décider des éléments qui sont pertinents et des détails qu’il

convient de négliger. C’est également un formalisme de spécification, c'est-à-dire qu’il

permet une description complètement non ambiguë et traitable par machine.

En fait (ainsi que le montre l’exemple que nous traiterons par la suite), le langage EXPRESS

peut être utilisé pour la spécification des données dans de très nombreux domaines autre que

la modélisation de produits. Par contre, à la différence des formalismes de modélisation

d’objets, tel que OMT17 ou UML18 [RBP91], il n’est pas destiné à modéliser des systèmes

informatiques faisant intervenir une composante dynamique [MEY88]. En EXPRESS, les

objets ne possédant pas de méthodes, et la connaissance procédurale représentable s’exprime

exclusivement soit sous forme de contraintes d’intégrité, soit sous forme de fonctions de

dérivations exprimant comment un attribut se calcule à partir d’autres attributs.

17 OMT : Abréviation de Object Modeling Technic. Méthode de spécification par modélisation des besoins à la mode en 1995, créée par J. Rumbaugh, et semblant s'imposer dans le monde anglo-saxon. 18 UML : Abréviation de Unified Modeling Language. Langage normalisé par l’OMG début 1997, permettant de décrire une application en fonction des méthodes objet avec lesquelles elle a été construite.


3.1.2 Les fondements du langage EXPRESS

Un modèle EXPRESS définit un ensemble d’entités qui représentent les objets à modéliser.

Chaque entité est définie par un ensemble de caractéristiques appelées attributs. Chaque

attribut possède un domaine de valeurs licites (type de données, pouvant eux-mêmes être des

entités). EXPRESS permet de préciser ces domaines grâce à des contraintes d'intégrité. Enfin,

conformément à l'approche objet [MEY88] [COA92] les entités sont organisées de façon

hiérarchique par des relations de généralisation/spécialisation associées à un mécanisme de

factorisation/héritage. L'exemple de la figure 2.2 présente une arborescence d'entités : deux

sous-types d'entités, étudiant et enseignant, sont des spécialisations d'un super-type d'entités

non instanciable (mot clé ABSTRACT), personne.

ENTITY personne

ABSTRACT SUPERTYPE OF

ONEOF (étudiant, enseignant);

END_ENTITY;

Figure 2.2 - Un exemple de hiérarchie de classes EXPRESS

Le langage EXPRESS permet de distinguer les instances d'entités et les simples valeurs. Ces

dernières peuvent appartenir aux types prédéfinis usuels (entier, réel, chaîne, etc.). Il est

également possible de construire des nouveaux types dit "types utilisateurs" (mot clé TYPE).

Ceci permet de donner un nom différent à un type existant, ou de construire, soit des types

énumérés et soit des types sélections (qui définissent une union de types).

La principale originalité d'EXPRESS est au niveau de la représentation des contraintes.

EXPRESS dispose seulement de deux abstractions de haut niveau qui expriment les

invariants des données, respectivement sous forme fonctionnelle et assertionnelle. La

dérivation permet de calculer de façon fonctionnelle un attribut à partir des autres éléments du

modèle. La contrainte d'intégrité, locale (clause WHERE) ou globale (GLOBAL), s'exprime

sous forme de prédicat qui doit être vrai pour toute donnée licite. Du point de vue syntaxique,

l'ensemble des constructions qui visent à représenter un univers est regroupé dans un

SCHEMA.

ENTITY étudiant SUBTYPE OF personne; END_ENTITY; ENTITY enseignant SUBTYPE OF personne; END_ENTITY;


Du point de vue sémantique, ce schéma définit avec beaucoup de précision un ensemble de

valeurs licites qui en constitue le domaine possible d'interprétation (i.e., l'ensemble de valeurs

autorisées).

Après adjonction de types de données, d'attributs et des contraintes nécessaires pour préciser

les propriétés que doivent respecter toutes les populations de données conformes au modèle,

le modèle de la figure 2.2, deviendrait par exemple (Figure 2.3):

Figure 2.3 - Un modèle de données contraint

Tout attribut, si cela est permis par le modèle (mot clé : OPTIONAL) y compris dans un

tableau (mots clés : ARRAY OF OPTIONAL), peut être autorisé à avoir la valeur

indeterminante. La clause WHERE introduit une contrainte d'intégrité locale destinée a être

SCHEMA etablissement_schema; TYPE t_salaire = REAL; WHERE

SELF > 0; END_TYPE; TYPE t_num_ss = STRING(13) FIXED; WHERE

wr: SELF[1] = '1' OR SELF[1] = '2';

END_TYPE; TYPE t_cours = ENUMERATION OF(

math, info, histoire, sport); END_TYPE; TYPE t_nom = STRING; WHERE

LENGHT(SELF) > 0; END_TYPE; ENTITY personne ABSTRACT SUPERTYPE OF

ONEOF (etudiant, enseignant);

num_ss: t_num_ss; nom: t_nom;

DERIVE initiale: STRING := calcule(SELF.nom);

UNIQUE ur: num_ss;

END_ENTITY;

ENTITY etudiantSUBTYPE OF personne;

Notes: ARRAY [1:5] OF OPTIONAL REAL; Suit: ARRAY [1:5] OF OPTIONAL cours;

WHERE wr: SIZEOF(QUERY(x <* notes | (x < 0) OR (x > 20))) = 0;

END_ENTITY; ENTITY enseignant SUBTYPE OF personne;

salaire: OPTIONAL t_salaire; enseigne: SET[1:?] OF cours;

END_ENTITY; ENTITY cours

intitulé: t_cours; INVERSE

est_suivi_par: SET[0:30] OF étudiant FOR suit; est_enseigné_par: enseignant FOR enseigne;

END_ENTITY; FUNCTION calcule(nom: t_nom): STRING;

RETURN(nom[1]); END_FUNCTION; END_SCHEMA ; -- etablissement_schema


vérifiée pour chaque instance d'un type ou d'une entité (les numéros de sécurité sociale ne

commençant pas par '1' ou '2' sont interdits).

La clause UNIQUE, contrainte d'intégrité globale au modèle mais exprimable localement,

indique l'unicité des valeurs d'un ou plusieurs attributs pour toutes les instances d'entités d'un

type d'entités (ici, il ne peut pas exister plusieurs personnes ayant le même numéro de sécurité

sociale). La clause INVERSE permet d'associer à toute relation, la relation inverse. Du point

de vue sémantique, il s'agit d'une méthode de dérivation implicite qui évalue, pour chaque

instance, l'ensemble des instances qui y font référence dans un rôle donné. Ce lien inverse

possède deux utilisations. D'une part, il permet d'exprimer la cardinalité d'une relation inverse

(tout cours est enseigné par un enseignant et un seul, il est suivi par un maximum de 30

élèves). D'autre part, il permet d'accéder à partir d'une instance, par la notation pointée, à

toutes les instances qui y font référence (par exemple pour savoir quels étudiants suivent un

cours donné, ou, dans un modèle géométrique de type B-rep, à quelle face appartient une arête

particulière).

Enfin, des fonctions prédéfinies permettent d'accéder à l'ensemble des instances d'un type

d'entité ou d'un agrégat (ensembles, listes, etc.), de les parcourir de façon indicée

(LOBOUND...HIBOUND) ou globale (clause QUERY), de calculer la taille d'un ensemble

(clause SIZEOF), d'accéder au type d'une entité, et, pratiquement, d'exprimer toute contrainte

susceptible de s'écrire sous forme d'un programme de type PASCAL (voir par exemple la

fonction calcule qui évalue l'initiale d'un nom en en prenant le premier caractère).

3.1.3 La notation graphique EXPRESS-G

La représentation textuelle des schémas EXPRESS est essentielle pour le traitement

automatique des modèles. C’est elle qui pourra être exploitée par machine pour vérifier sa

correction, ou vérifier si les instances lui sont conformes. Elle est , par contre, assez

difficilement lisible. Un formalisme graphique, EXPRESS-G [ISO94a], a donc été défini pour

donner une vue synthétique des modèles de données et faciliter leur conception dans les

phases initiales d’analyse des problèmes à modéliser. Ce symbolisme de représentation n’est

que partiel et ne permet pas d’exprimer les contraintes d’intégrité. La nature des attributs


(optionnel, dérivé ou inverse), ainsi que leur type, peuvent par contre être représentés. La

représentation en EXPRESS-G du modèle de données précédent est donnée dans la figure 2.4.

Figure 2.4 -Représentations en EXPRESS-G d’un modèle de données [SAR99]

3.1.4 Intérêt d’EXPRESS

A la différence des nombreuses notations existantes pour modéliser des données telles que

OMT ou UML qui ne sont que graphiques et donc seulement échangeable entre êtres

humains, le fait, pour EXPRESS, de posséder à la fois une version graphique et une version

textuelle rend ce langage traitable par machine. Un modèle EXPRESS peut être échangé entre

label Entité

label Type atomique

label

label

Type utilisateur

Type énuméré

Relation d’héritage

Relation d’association

Relation d’association optionnelle

(DER) label Label est un attribut dérivé (INV) label Label est un attribut inverse S[a :b] Ensemble d’au moins a et d’au plus b éléments A[a :b] Tableau de b-a+1 éléments


machines différentes. Il peut également être traité par machine pour en vérifier la cohérence,

ou pour passer automatiquement de la version graphique à la version textuelle et inversement.

Il peut enfin être exploité pour générer automatiquement différents programmes ou

représentations informatives tels que le schéma d'une base de données susceptible d'en stocker

les instances. Il s'agit donc bien à la fois d'un modèle interprétable par l'utilisateur humain, et

d'une spécification interprétable par machine. Comparé aux autres notations existantes,

EXPRESS possède les points forts suivants :

• Ιl s’agit d’un standard international stable, bien documenté et de plus en plus utilisé,

• Il possède une syntaxe et une sémantique précises autorisant, avec des outils

appropriés, une interprétation et un traitement automatique des modèles,

• Il possède une représentation graphique qui fournit une vue synthétique du modèle

pour mieux le comprendre ou le concevoir,

• Ιl possède un système de contraintes complet (contraintes de cardinalité, contraintes

ensemblistes, contraintes assertionnelles, contraintes fonctionnelles, contraintes sur les

classes, etc.), ainsi qu'un langage procédural permettant d'enrichir celles-ci, enfin il

permet la réutilisation, grâce à sa modularité, des schémas de ressources existants et

autorise donc un développement incrémental de modèles de plus en plus vastes et

complexes.

De plus EXPRESS est associé à des méthodes d'échange et d'accès aux données, et à des

outils de génération automatique permettant de générer des programmes de traitement

conformes à ces méthodes d'échange et d'accès.

3.2 Méthodes de mise en œuvre

Ce sont les méthodes, prédéfinies et normalisées, de représentation d’instances conformes à

un modèle EXPRESS. Ces méthodes de mise en ouvre vont permettre à la fois l’échange de

données entre systèmes hétérogènes, et l’archivage de données dans un format indépendant du

système source.


3.2.1 Représentation des instances sous forme de fichier neutre

Ce mode de représentation des instances d’un modèle défini en EXPRESS est spécifié dans le

fascicule 21 de STEP [ISO94b]. Cette spécification définit la manière de coder sous forme

d’un fichier de caractères, une population d’instances d’entités conformes à un modèle défini

en EXPRESS. Ce fascicule spécifie :

• les alphabets utilisables et le codage des différentes structures lexicales,

• la structure des fichiers,

• le contenu des entêtes de fichiers,

• les règles de traduction de définition en EXPRESS,

• le format physique des fichiers.

Un exemple commenté d’instances du modèle de données que nous avons décrit dans la

figure 2.5 est présenté ci-dessous :

Figure 2.5 - Exemple d’un fichier physique

On peut noter que chacune des instances est identifiée par un oid (object identifier), est

caractérisée par le nom de la classe instanciée, et contient la suite de valeurs de ses attributs

ISO-10303-21; HEADER; FILE_DESCRIPTION(('ceci est un test','le fichier contient la description de ...'),'1') FILE_NAME('Fichier.STEP','2002-08T15:12:30','Imad El Khalkhali','PRISMa',France'); FILE_SCHEMA('etablissement_schema'); END_SEC; DATA; #1 = ETUDIANT ('1700975121457', /* num_ss, hérité de la classe personne */

'Dupont', /* nom, hérité de la classe personne */ (15.5, 12.0, $, $, $), /* notes, le tableau de réels optionnels*/ (#5, #6, $, $, $)); /* suit, référence aux instances de cours correspondants*/

#2 = ETUDIANT ('2700286054018', 'Durand', (5.0, 19.0, $, $, $), (#5, #7, $, $, $)); #3 = ENSEIGNANT ('1541211100004', 'Martin', $, (#5, #6)); #4 = ENSEIGNANT ('1600366015259', 'Dupont', $, (#7))); #5 = COURS(.MATH.); #6 = COURS(.INFO.); #7 = COURS(.SPORT.); .. END_SEC; END-ISO-10303-21;


entre parenthèses. Les collections de valeur sont également présentées entre parenthèses, la

valeur "indeterminate" (des attributs optionnels) est désignée par '$', et les valeurs des types

énumérés par une notation entourant l'identificateur par un point à chacune de ses extrémités.

On peut aussi remarquer que les attributs dérivés et inverses ne sont pas représentés. En effet,

lors d'un échange de ce fichier d'instances, le système receveur basé sur le même modèle de

données pourra recalculer ces attributs. Un tel fichier permet à deux systèmes informatique

d'échanger sans aucune ambiguïté des populations d'instances conformes à un modèle

EXPRESS.

3.2.2 L’interface SDAI

En plus de la méthode d’échange de données définie à travers la notion de fichier neutre, une

méthode de partage des instances d’un modèle EXPRESS entre systèmes hétérogènes a

également été définie. Celle-ci basée sur la définition d’une bibliothèque de fonctions d’accès

normalisées (une interface d’accès), et est connue sous le nom SDAI (Standard Data

Interface) [ISO97]. Cette interface permet en particulier :

• l’accès et la manipulation par programme d’instances d’entités définies en EXPRESS,

• l’accès simultané à plusieurs bases de données par plusieurs applications,

• la vérification des contraintes définies dans le modèle de données EXPRESS.

La spécification décrite dans le fascicule 22 définissant l’interface d’accès normalisé

indépendamment de tout langage de programmation, des syntaxes d’appel dans les langages

de programmation tels C, C++ ou JAVA ont également été définie dans les fascicules 23, 24

et 27 [ISO00a] [ISO01] [ISO00b]. Les applications souhaitant accéder à des modèles de

données EXPRESS, et manipuler des instances relatives à ceux-ci, font appel aux services

fournis par ces interfaces. Elles peuvent alors s’exécuter sur n’importe quel système

supportant la même interface normalisée.


3.2.3 Génération d’applications à partir d’un modèle EXPRESS

De nombreux outils existants19, gratuits ou commercialisés sur le marché permettent de

générer automatiquement à partir d’un modèle EXPRESS :

• une base de données susceptibles de stocker les instances de ce modèle,

• une interface normalisée (SDAI) d’accès à cette base de données,

• un programme de lecture d’un fichier neutre conforme à ce modèle et capable de

stocker son contenu dans la base de données par appel de la SDAI.

• un programme d’écriture d’un fichier neutre conforme à ce modèle et capable de lire

son contenu dans la base de donnée par appel de la SDAI, puis de générer un fichier.

Il s’agit donc d’une véritable application générée de façon complètement automatique. Ceci

montre l’intérêt considérable du langage EXPRESS, en particulier lorsqu’on le compare aux

formalismes tels que OMT ou UML.

3.3 Les modèle de données STEP

Le projet STEP n’a pas seulement défini des outils et méthodes, il a également, dans un

nombre croissant de domaines, défini des modèles.

3.3.1 Les ressources intégrées

les ressources intégrées fournissent des informations génériques et indépendantes du contexte

qui peuvent être utilisées par plusieurs applications. Il existe deux types de ressources

intégrées : les ressources génériques et les ressources d’application intégrées.

3.3.1.1 Les Ressources Intégrées Génériques

Les ressources intégrées génériques se composent d’un ensemble de modèle de données

génériques, indépendant du type de produit, du type d’application et de processus de

19 Ces outils sont disponible sur le site : http://www.steptools.com.


fabrication. Cet ensemble de modèles définit un produit industriel générique et ils ont une

applicabilité générale. La liste suivante montre des exemples de ces modèles :

Partie 41 : Eléments fondamentaux de description de produit

Partie 42 : Représentation géométrique et topologique

Partie 43 : Structure et représentation

Partie 44 : Configuration et structure de produit

Partie 45 : Matériaux

Partie 46 : Présentation visuelle

Partie 47 : Tolérances

Partie 48 : Form Features

Partie 49 : Structure de processus

3.3.1.3 Les Ressources Intégrées d’Application

Un ensemble de données génériques ne suffit pas pour définir les données nécessaires à une

application particulière ou à une série d’applications similaires. On trouve un certain nombre

de données dites applicatives qui ne sont utilisées que pour un domaine applicatif particulier.

Il s’agit par exemple du modèle de maillage pour les applications d’analyse par éléments

finis, cinématique ou draughting (dessin technique), etc… La liste suivante montre les parties

définies actuellement comme des ressources intégrées d’application :

Partie 101 : Dessin technique

Partie 103 : Application électrique

Partie 104 : Analyse éléments finis

Partie 105 : Cinématique

Les données que l’on trouve dans ce type de modèle peuvent être des spécialisations de

données génériques ou bien des entités complètement autonomes.


3.3.2 Les protocoles d’application STEP

Mais les approches génériques ne suffisent pas. La caractéristique de chaque métier est

d’avoir élaboré son propre savoir faire par spécialisation du savoir faire commun aux

différents métiers techniques. Un ingénieur de calcul n’utilise pas le même langage qu’un

responsable de production, de même qu’un électricien ne s’intéresse pas aux même objets

qu’un plombier. C’est à ce niveau de spécialisation que les données réelles doivent être

conservées, et si possible articulées avec les niveaux voisins. C’est, dans STEP, le niveau des

protocoles d’applications. De façon à intégrer le mieux possible les besoins des utilisateurs,

l’ISO propose une méthodologie pour l’élaboration de ces protocoles d’application. Cette

méthodologie, qui est une approche de type top-down, impose le passage par les phases

suivantes résumées sur la figure 2.6:

Figure 2.6 - Cycle de développement d’un AP

Nous vous présentons dans ce qui suit les différentes phases de cette méthodologie :

1. Spécification du besoin qui consiste à spécifier le besoin en information du point de vue

des utilisateurs.

2. Application Activity Model (AAM) qui est une phase au cours de laquelle le modèle

informationnel du domaine d’application de l’AP est construit. Cela permet de mettre en

évidence les différentes activités du domaine et les flux d’information entre celle-ci, et

d’établir un glossaire du vocabulaire utilisé. On en déduit les activités et flux

Spécification du besoin

Définition deL’AAM

Définition deL’ARM

Définition deL’AIM

Mapping

RessourcesIntégrées

Protocole

d’application


d’information à prendre en compte pour la suite des travaux. Cette modélisation est faite

à l’aide du formalisme IDEF0.

3. Application Reference Model(ARM) qui est une phase au cours de la quelle sont définis les

UoFs et le modèle de données utilisateur sur la base de l’AAM. Un UoF (Unit of

Functionnality) ou unité fonctionnelle consite en un regroupement d’objets participant à

une fonction donnée dans le domaine d’application. Le modèle de données utilisateur

correspond à une formalisation avancée des données manipulées par les utilisateurs en

utilisant le vocabulaire de ceux-ci. Cette modélisation est faite à l’aide d’un des

formalismes IDEF1X, NIAM ou EXPRESS.

4. Application Interpreted Model (AIM) qui est la phase au cours de laquelle le modèle de

données de référence est défini à partir de l’ARM et des Ressources intégrées. Cette

opération appelée mapping consiste en une mise en correspondance des données

utilisateur et avec les ressources intégrées génériques et applicatives. Pour cela on

construit une table de correspondance qui contient, pour une entité utilisateur, l’entité de

l’AIM correspondante, la ressource intégrée source, le chemin d’accès à cette entité dans

la structure de données de ressources intégrées, et les règles globales et/ou s’appliquant à

l’entité. Le modèle de référence est modélisé en EXPRESS. Deux modèles peuvent alors

être produits : la forme courte qui ne donne pas la définition EXPRESS des entités

reprises des ressources intégrées mais les référence par REFERENCE FROM et USE

FROM, et la forme longue qui donne la définition EXPRESS du protocole d’application

dans sa globalité.

La figure 2.7 liste l’ensemble des protocoles d’application, développés ou en cours, et montre

la très grande variétés des domaines applicatifs couverts. Par la suite les protocoles

d’application 203 et 214 seront détaillés. Le 203 [FER98] définit un modèle de données pour

la mise en œuvre du Système de Gestion de Données Techniques couplé à des systèmes CAO

dans les industries mécaniques. Plus ambitieux encore, le 214, élaboré par l’ensemble des

fabricants automobiles du mondes entier, propose une définition des données nécessaires pour

représenter des produits aussi complexes que les véhicules automobiles tout au long de leur

cycle de vie.


Figure 2.7 - Quelques Protocoles d’Application

Le protocole d’application 203

Le protocole d’application 203, normalisé depuis 1994, a pour objectif de couvrir les données

associées à un produit lors de sa phase de conception, de type géométrique, définition et

contrôle de configuration de ces produits. Le modèle utilisateur ARM se compose des UoFs

suivants :

- Part identification qui permet la description d’un composant (pièce ou assemblage), de

ses versions et des différentes vues associées à ce composant.

- Bill of materials qui permet la définition de la structure d’un produit (nomenclature) en

termes de composants ou matériels.

- Design information qui permet la définition d’informations, autres que de géométrie et de

configuration décrites dans cette partie, relatives à un produit.

- Autorization qui permet, pour des autorisations/acceptations relatives à un produit, la

description des dates, des personnes habilitées et des niveaux de confidentialité.

- Effectivity qui permet la définition des informations de validité d’utilistion d’un

composant relatives à une configuration donnée du produit.

- Source control qui permet l’identification des personnes et organisations responsables de

la fourniture d’un produit.

- Design activity control qui permet la description de l’historique des versions d’un produit,

des demandes et ordres de création et de modification.

Partie 201 : Dessin technique explicite Partie 202 : Dessin technique associatif. Partie 203 : Conception mécanique 3D avec gestion de configuration Partie 207 : Conception des outils et gammes pour l’emboutissage Partie 208 : Processus de modification, du cycle de vie d’un produit. Partie 209 : Analyse par éléments finis de structures métalliques et composites Partie 213 : Plans de procédés de contrôle numérique pour gammes d’usinage Partie 214 : Données pour la conception mécanique d’automobiles Partie 219 : Gammes pour machines à mesurer Partie 222 : Conception et fabrication de structures composites Partie 223 : Conception et fabrication de pièces moulées Partie 224 : Formes fonctionnelles utilisées lors de l’élaboration de gammes de fabrication.


- End item identification qui permet l’identification des produits et de leurs configurations

commercialisables.

- Shape qui se compose de cinq types de représentation géométrique, la géométrie filaire et

surfacique sans topologie, la géométrie filaire avec topologie, la géométrie BREP

facettisée et la géométrie BREP exacte.

Ainsi dans un seul fichier d’échange, on peut avoir, dans le cas d’un assemblage [FER98] :

- Une ou plusieurs descriptions géométriques de chacun de ces composants et leurs

variantes et versions, en utilisant le concept de vue sur un produit,

- La structure de l’assemblage sous forme de nomenclature et/ou de pièces positionnées par

introduction d’une matrice de transformation géométrique appliquée à un produit, une

version ou une variante de celui-ci,

- Les différentes configurations et variantes de cet assemblage,

- L’historique du cycle de création et de modification du/des produits,

- Les informations concernant les différents acteurs et organisations ayant participé à

l’élaboration de l’assemblage et de ses composants, leur niveau d’approbation, etc,

- Les références des documents utilisés tout au long du cycle de conception du produit

(cahier des charges, normes, dossiers de modification, etc.).

Le protocole d’application 214

Le protocole d’application 214 a pour objectif de traiter la conception mécanique

d’automobiles, et plus généralement, la conception mécanique de produits à forte diversité,

destinés à être produits en grande série [MOH97].

Ce protocole d’application est depuis le début des travaux de STEP, le chantier de plus grande

envergure lancé au sein de l’ISO. En effet, le nombre et la diversité des domaines couverts par

les Uofs décrits ci-dessous donne un bon aperçu sur la taille et la complexité traitées dans

cette partie [HUA97] :


- Structuration des produits qui permet la définition des produits (pièces et /ou outils),

versions de produit, vues d’une version dans un contexte ainsi que les relations entre ces

vues, emboîtement de produits et introduit le concept d’instance physique d’un produit.

- Données administratives qui permet l’identification des personnes, organisations, dates,

approbation, confidentialité, des associations de personnes, organisations, dates,

approbation ou niveau de confidentialité à des données de produit.

- Classification qui permet la définition de classification spécifiques ou par des attributs.

- Gestion des articles par critères qui introduit le concept de classe d’articles (produits

commercialisables), de critères de spécification des articles, de catégorie de critère, de

packages. Il permet les combinaisons booléennes de ces critères et d’exprimer les cas

d’emploi d’une solution ou d’une opération de gamme, la définition

d’applicativité/effectivité par numéro de lot, par numéro de série ou par dates.

- Découpage fonctionnel et solutions qui permet la manipulation des notions de

fonctionnalités (domaine de définition, hiérarchie des fonctions…), de solutions (solutions

technique, diversité fournisseur, association pièce neutre-pièce colorée, éléments de

solution), certaines de conception et d’homologation d’une solution.

- Gestion des ordres de travail qui permet la définition des demandes, objets et ordres de

travail, d’activités, des projets (relations entre projets, planification), des contrats.

- Groupes, niveaux qui permet la définition de types de valeurs par défaut telles que la

rugosité, la chanfrein, l’angle de dépouille, le congé, l’arrondi, le tableau de tolérances, et

de leur contexte d’application.

- Mécanisme de référence externe qui permet l’identification de documents externes, leur

affectation à une donnée de produit et de modèles externes.

- Mise en plan qui permet la définition de paramètres et de critères d’apparences graphiques

(hachurage, remplissage, échelle, projection…), d’annotations, d’associations d’un dessin

à des données de produits.

- Dessin technique qui permet la définition de symboles d’annotation, de cotes, de textes

graphiques…

- Dimensionnement qui permet la caractérisation d’un produit en termes de taille (longueur,

largeur, hauteur, poids), de position.


- Géométrie qui permet la définition géométrique de produit au moyen de représentations

filaire 2D, filaire 3D avec et/ou sans topologie, surfacique avec topologie, solide

facettisée, solide BREP, CSG ou hybride 3D (tous les types de représentation mélangés).

- Form-features qui permet l’utilisation de features de conception et de features de

fabrication. Plusieurs catégories de features sont disponibles : les features volumique

(poche, nervure…), les features de transition (arrondi, congé, chanfrein…), les features

répliquées et les features non-standard.

- Cinématique qui permet la définition de modèles cinématique, de mécanismes, de

structures cinématiques (topologie décrite au moyen de liaisons et de nœuds), de

mouvements autorisés, de configuration initiale.

- Données de mesure qui permet la définition d’un ensemble de listes de points cartésiens et

de listes de points sur surface ou de couple (point, direction).

- Tolérance géométriques qui permet la définition de tolérances géométriques,

l’identification des éléments tolérancés et des éléments éléments de référence.

- Conditions de surface qui permet la définition de conditions de surfaces, en termes de

propriété et d’opération pour son obtention, tels que le traitement de surface, l’apparence

visuelle, la qualité tactile, la dureté, la rugosité, l’enduit, le coefficient de contact.

- Propriétés qui permet la définition des propriétés d’une pièce (coût, géométrie, centre de

masse, etc), l’identification des matériaux.

L’AP214 permet une représentation complète des données de conception d’un produit destiné

à être produit en grande série. Il introduit la nomenclature dite variationnelle qui permet la

description de nomenclatures ) l’aide de critères ou attributs et de ne pas avoir à décrire de

façon explicite toutes les variantes de nomenclature pour un produit. Par exemple, dans le cas

du produit automobile, le nombre de nomenclatures différentes dépend du nombre de

versions, d’options et d’autres attributs, ce qui devient impossible à gérer, compte tenu de la

combinatoire et du nombre de composants. En ce sui concerne la représentation géométrique,

l’AP214 inclus, en plus de l’AP203, la représentation CSG et le concept de modèle hybride

autorisant le mélange des types de représentation.


Parmi les autres protocoles d’application, nous pouvons aussi citer le :

• Protocole d'application 201 : dessins détaillés. Ce protocole d'application permet

d'échanger des dessins techniques CAO comportant des données géométriques et des

images bi-dimensionnelles. Les ingénieurs d'études et autres ingénieurs interpréteront

ces dessins en utilisant des normes acceptées à l'échelle de l'organisme, du pays et du

monde entier. Bien que ce protocole d'application soit en place depuis quelques

années, il n'est pas beaucoup utilisé à l'échelle mondiale.

• Protocole d'application 202 : dessin associatif. Ce protocole d'application permet

d'échanger des dessins techniques CAO comprenant des images bi-dimensionnelles de

données géométriques ou d'images planaires à deux ou à trois dimensions définies

dans un espace bi-dimensionnel ou tri-dimensionnel. Il renferme également des

données relatives à la révision, à l'organisation et à la gestion, à l'appui de l'ensemble

du développement d'un produit jusqu'à la fin de son cycle de vie. Ce protocole

d'application a commencé à intéresser les fournisseurs CAO, mais sa mise en oeuvre

commerciale est encore limitée et on ne le trouve qu'en version bêta.

• Protocole d'application 224 : définition des pièces mécaniques pour la planification

des processus utilisant l'usinage. Ce protocole d'application peut constituer la base de

l'intégration de la conception des pièces à la planification des processus et aux

fonctions d'ordonnancement de la production du système de planification des

ressources de l'entreprise. Il est récemment parvenu au terme de son évolution et on

peut s'en procurer une version commerciale sur la plateforme ProEngineer par le biais

d'un fournisseur intermédiaire. Des outils d'aide d'autres plateformes CAO pourraient

être disponibles d'ici un an ou deux ans.

• Protocole d'application 232 : présentation des données techniques : information de

base et échange de données. Cette série de données représente l'ensemble des données

techniques requises par les pouvoirs publics pour constituer la documentation des

produits. Bien que la totalité du progiciel ne soit pas disponible selon un modèle

d'information STEP officiel, le protocole d'application précise les extensions à mettre

impérativement en oeuvre pour intégrer les données à un progiciel de fichiers à

configuration gérée par le STEP.


• Le protocole d'application 208 : qui porte sur le processus de modification des

produits au cours de leur cycle de vie. Certains analystes font valoir que ce protocole

est au cœur de la gestion de la configuration.

• Le protocole d'application 213 : qui prévoit le processus de contrôle numérique des

pièces usinées, lequel rattache l'ensemble du processus aux opérations et à l'utilisation

du matériel de l'usine.

3.3.3 Les constructions interprétées applicatives

Sous l’acronyme AIC (Application Interpreted Construct) se trouve un concept qui vise à

garantir l’interopérabilité des protocoles d’application. Une construction interprétée

applicative (AIC) fournit un groupement logique des constrcutions interprétées qui supporte

une fonctionnalités spécifique pour l’utilisation de données de produit à travers des contexte

des applications multiples. Une AIC est une interprétation des ressources intégrées qui

supporte les besoins d’information partagés entre les protocoles d’application.

Par exemple pendant le développement des protocoles d’application 201 et 202, les

développeurs se sont rendu compte qu’il existe des parties de protocoles d’application qui

utilisent les mêmes interprétations des ressources intégrées. Pour éviter la reproduction de ces

ensembles et garantir le concept de réutilisation ils ont groupé des interprétations dans les

parties séparées des AIC pour l’utilisation des AP suivants.

3.4 Les tests de conformité

Instruites par les difficultés rencontrées dans les interfaces de la génération précédente (telle

que IGES) où il était très difficile, en cas d’anomalie dans un transfert de données, d’identifier

les responsabilités entre l’émetteur, le receveur, voire les erreurs ou imprécisions de la

spécifications elle-même, la norme STEP définit pour chaque AP [ISO98] :

- comment doivent être testées les interfaces ?

- sur quels critères établir leur conformité ?


A l’ISO, des projets de normes définissant les tests de référence sont en cours de

développement pour les AP202, 203, 204, d’autres testes de référence doivent être

progressivement développés pour tous les protocoles d’application.

En France, une norme expérimentale pour l’AP 203 (AFNOR Z 68 333), un laboratoire de

Tests au GOSET, et un Comité de Certification NF à l’AFNOR sont déjà disponibles.

Certaines interfaces sont d’ores et déjà certifiées conforme pour ce protocole d’application

dont le déploiement est actuellement le plus avancé.

4. Conclusion

Dans ce chapitre, nous avons présenté le Standard STEP qui reste le premier standard

international pour l’échange et la représentation des modèles de données de produit.

L’objectif de STEP est de définir une représentation non ambiguë du produit en couvrant son

cycle de vie. Pour cela, STEP propose des langages, des modèles de données et des méthodes

pour développer ces modèles de données.

Au niveau langage, le langage EXPRESS apparaît comme le formalisme de spécification le

plus avancé aujourd’hui pour la représentation des données hautement structurées telles qu’on

les rencontre dans la modélisation de produit. Il permet d’exprimer n’importe quel type de

contraintes. Il spécifie à la fois des formats d’échange et d’archivage, et des interfaces

d’accès. Enfin le fait qu’il soit traitable par machine le rend encore plus intéressant par

rapport à d’autres formalismes tels que UML ou OMT (les programmes de lecture de fichiers

d’échanges et les interfaces d’accès à des bases de données peuvent être générées

automatiquement à partir du seul modèle de données).

Au niveau des modèles de données, STEP définit à la fois des ressources génériques pour la

modélisation des produits, et des modèles complet et finalisées pour un certain nombres de

domaines appelé Protocoles d’Application.


Quant à la définition de modèles de produit conformes à STEP, ce dernier propose une

méthodologie pour le développement de protocoles d’application. Cette méthodologie peut

être utilisée pour élaborer des modèles normalisés de produit propres à chaque organisation.

La revue des travaux de recherche qui s’intéressent à la norme STEP présentée dans la

première partie de ce chapitre a montré que les efforts se sont essentiellement focalisés sur

l’échange, le partage et l’intégration des données, et que les travaux qui s’intéressent au

contenu des modèles de données de STEP sont rares. Un certain nombre des difficultés

rencontrés lors de développement collaboratif de produits restent en effet non traitées. C’est

l’objectif du chapitre suivant de préciser la problématique de notre travail et présenter

l’approche envisagée pour répondre à cette problématique.

Chapitre 3. Précision et approche de la problématique 53

Chapitre 3

Précision et approche de la problématique

1. Introduction

Dans le chapitre précédent nous avons étudié la norme STEP avec ses langages descriptifs,

ses modèles de données et ses méthodes de mise en œuvre. Cependant un bon nombre de

problèmes liés au développement collaboratif de produit restent non traités et non pris en

compte par la norme STEP. C’est l’objectif de ce chapitre, de préciser la problématique de

notre travail et de présenter l’approche envisagée, en tirant profit des développements

théoriques dans le domaine de la conception et la fabrication intégrées.

Ce chapitre est organisé en deux parties. La première partie a pour objectif d'abord de poser

les hypothèses principales sur lesquelles se basent la définition de la problématique et le

travail réalisé et ensuite de préciser les objectifs de ce travail de thèse. La deuxième partie a

pour objectif de puiser dans la littérature des méthodes et des moyens susceptibles de réaliser

le cahier de charges posé dans la première partie, afin de fixer les éléments clés sur lesquels se

base le travail proposé. Elle constitue ainsi la base théorique du travail développé.


2. Précision de la problématique

Il est vite apparu que la prise en compte des points de vue des acteurs intervenant dans un

projet est indispensable pour une modélisation complète et efficace des produits et des

processus. En effet les acteurs travaillant simultanément au projet sont nombreux et de

spécialités très différents : Client, commercial, concepteurs, fabricant, etc. Les points de vue

qu’ils portent sur le produit sont également très différents comme illustré dans la figure 3.1.

Figure 3.1 - Pluridisciplinarité de la conception de produit

Plusieurs définitions sont proposés dans la littérature pour la notion de point de vue.

Rosenman [ROS96] précise que la notion de point de vue est définie dans le modèle de

produit pour permettre la prise en compte des différentes perceptions qu’ont les concepteurs

du produit.

En effet, la description de base d'un produit diffère d'un concepteur à l'autre, comme elle peut

différer pour un même concepteur en tenant compte de certain facteurs propres au concepteur

tels que la pluridisciplinarité. Chaque concepteur représente un produit avec des éléments

différents et des compositions hiérarchiques différentes. Chaque point de vue et chaque

représentation de concepteur doivent donc être intégrés dans une représentation cohérente du

produit.

Point de vue Fabrication

Points de vue Marketing Points de vue

Conception


Malheureusement les modèles STEP ne permettent pas la prise en compte de cette notion,

alors que cette notion est fondamentale pour une conception collaborative et intégrée.

Signalons également que les modèles de STEP sont statiques et ne fournissent qu’une

représentation partielle du produit, ils n’assurent que la structure et la géométrie et le lien avec

la fabrication reste incomplet. Il s’agit aussi du manque de modèles d’expression des besoins

suffisamment compréhensibles pour assurer une communication efficace et non ambiguë

entre les acteurs concernés, et qui ne fasse pas ralentir le développement des produits à cause

des multiples itérations nécessaires pour préciser les besoins et valider les spécifications.

Une autre critique faite aux modèles STEP est qu’ils ne prennent pas en compte la notion de

projet et donc ne savent pas structurer les points de vues relatifs au produit par rapport au

projet.

Des travaux d’extensions des modèles de STEP existent mais présentent comme inconvénient

de n’être guidés par aucune méthodologie au niveau de la structuration des informations

contenues dans les modèles ce qui provoque des erreurs de sémantique importantes. La même

remarque peut être également faite sur la construction des modèles initiaux eux-mêmes.

C’est sur ces hypothèses que se base la définition de notre problématique et le travail réalisé.

Ainsi le travail de thèse présenté dans ce mémoire a pour objectif de mettre en place un cadre

méthodologique et applicatif pour enrichir les modèles de STEP en abordant les deux aspects

qui sont :

• La mise en place d’une méthodologie pour construire l’ensemble de modèles à différents

niveaux d’abstraction permettant de prendre en compte les points de vue de l’ensemble

des acteurs.

• La mise en place d’une infrastructure informatique pour le stockage et le partage de ces

modèles ainsi que d’autres informations de produit dans le contexte de l’Entreprise

Virtuelle.

Tel est le cahier des charges du travail de thèse proposé. Dans la partie suivante nous puisons

dans la littérature sur les modèles et approches pour la conception et la fabrication intégrées

qui pourraient permettre de satisfaire au mieux le cahier des charges ainsi posé.


3. Modèles et approches pour la conception et la fabrication intégrées

Cette partie a pour objectif de dresser un état de l’art, suffisamment exhaustif, des études

identifiées pouvant aider à résoudre la problématique présentée ci-dessus.

3.1 Les modélisations Produit-Processus

3.1.1 La théorie des Domaines

[AND91] présente une théorie de la conception s’appuyant sur un ensemble de concepts, de

règles, d’axiomes et de modèles. La représentation d’un système mécanique est faite selon

quatre domaines : (1) domaines des phénomènes, décrivant les transformations physiques qui

ont lieu dans le système, (2) domaine des fonctions, exprimant les résultats attendus du

système, (3) domaines des organes, représentant les entités qui répondront aux résultats

attendus du système, (4) domaines des pièces, précisant les éléments réalisationnels

(composants ou pièces) des organes du système. La conception s’appuie sur la modélisation

par domaine, pour aller d’une description abstraite vers une description concrète d’un système

mécanique. Les domaines entretiennent des relations causales, permettant le passage de l’un à

l’autre dans le modèle. Le produit est défini à l’aide d’une représentation génétique, le

chromosome, traduisant les résultats de conception. Cette représentation s’appuie sur les

éléments des quatre domaines (Figure 3.2).

Figure 3.2 - Le chromosome [AND91]


Le travail du concepteur s’effectue à l’aide de trois opérations basiques [MOR96] modifiant

la composition du chromosome et influant sur les éléments des domaines : detatching

(séparation), synthesis (synthèse) et weawing (insertion). L’opération detatchning permet de

séparer un élément de conception du modèle produit, de l’ajuster afin de satisfaire un besoin

spécifique. L’opération synthesis assure la création d’un nouvel élément de conception à partir

de la composition ou décomposition des éléments déjà existants de façon intra ou inter

domaines. L’opération weawing traduit l’insertion dans le modèle produit d’un nouvel

élément, en créant les relations nécessaires avec son environnement.

3.1.2 Le Modèle Intégré de Définition de Système Mécanique (MIDSYM)

Le projet MIDSYM (Modèle Intégré de Définition de Système Mécanique) développé par

Mony [MON92], a permis de mettre en place les premiers éléments d’un modèle de produit

pour l’ingénierie de produit. Son objectif est la conception d’un modèle informationnel, qui

intègre toutes les informations (géométriques, fonctionnelles, technologiques et physiques)

nécessaires à la définition du produit. Ce modèle a été implémenté dans une base de données

objet (GEMSTONE) qui sert de base à tout échange d’informations sur le produit déjà conçu.

Le niveau de description des données du modèle est défini par le stockage minimum de

sémantique autorisé pour permettre le partage des données vers les différentes vues

applicatives. Mony propose un modèle intégrant l’ensemble des paramètres géométriques,

fonctionnels, physiques et technologiques qui entrent dans la définition d’un système

mécanique. Ceci permet une capitalisation des informations produit dès la conception, un

partage et un enrichissement de ces informations par différents métiers ainsi qu’une

capitalisation du savoir faire au travers des informations stockées.

3.1.3 Le modèle par couche

Les travaux de Crabowski [CRA95] utilisent les principes de modélisation par couche en

fonction des phases du développement du produit (modélisation du besoin, modélisation

fonctionnelle, modélisation des principes- ou d’idées de solution- et de modélisation des

formes). L’évolution dans les couches du modèle s’effectue par une progression par états de

solutions successifs.


Un ensemble d’opération permet de passer d’un état de solution à un autre : concrétisation,

abstraction, description, combinaison et alternat :

• La concrétisation : permet de passer à un état de solution ESi à un état ESi+1 mais d’une

couche de modélisation inférieure,

• L’abstraction : opération opposée à la précédente,

• La description : permet de passer d’un état de solution ES à un état de solution ESi+1

mais dans la même couche. Cette opération consiste en un apport d’information à un état

donné du produit.

• La combinaison : opération opposée à la précédente,

• L’alternat : permet de prendre en considération plusieurs alternatives d’état de solutions

ESi pour l’état ES.

3.1.4 Le modèle FBS

La méthode de conception FBS (Function-Behavior-State) développée par UMEDA

[UME90] [UME96], comporte plusieurs étapes et leurs modèles associés. La première étape

est la définition des besoins, exprimés dans un cahier des charges par le client. Les besoins

expliquent pourquoi un objet est ce qu’il est. Ensuite il faut analyser ces fonctions pour en

déduire l’ensemble des fonctions (Function) qui vont caractériser le produit. Les fonctions

seront décomposées en sous-fonctions, les concepteurs déterminent les comportements

(Behavior) qui vont être associés au produit. Ces comportements répondent à la

question suivante : comment le produit va t-il réaliser les fonctions qui lui sont associées.

Enfin, les comportements du produit amènent le concepteur à l’élaboration de la structure

(State) du produit. Cette structure donne des informations sur la manière dont les différents

composants qui sont contenus dans le produit sont associés ensemble.

Une évolution du modèle FBS est proposée dans [SHI98] avec le modèle FEP(Functional

Evolution Process). Ce modèle représente la mise en oeuvre des entités function dans le

processus de conception. La description fonctionnelle de l'objet à concevoir est graduellement

affinée et détaillée. Le processus se décompose en étapes déclinables en trois activités :


functional description, functional actualization et functional evaluation. L'activité functional

description revoit, modifie et améliore le modèle, à chaque nouvelle étape du processus.

L'activité functional actualization correspond à la traduction en terme d'entités behavior des

entités function modifiées lors de la description. L'activité functional evaluation assure le

contrôle de la conformité entre les descriptions des entités function et behavior .

3.1.5 Le modèle produit de MOKA

MOKA (Methods and tools Oriented Knowledge Acquisition) [MOK99] est une méthode

issue d’un projet européen ESPRIT/AIT qui a commencé en 1998. Les objectifs de ce projet

ont été de définir une méthodologie pour réaliser des applications KBE (Knowledge Based

Engineering). Les résultats comprennent la proposition d’un modèle du produit et du

processus basé sur le formalisme UML.

Le modèle de produit décrit le pourquoi de la conception. Le modèle inclut des vues, classes

et des attributs prédéfinis. Il y a 5 vues dans le modèle de produit (Figure 3.3) :

• La vue structure inclut les classes : structure, produit, assemblage, pièce, feature

composite et classe feature. C’est la vue principale du méta modèle à partir de laquelle les

autres liens sont faits.

• La vue fonction inclut les classes : Fonction, principe de solution, solution technique.

Cette vue est en liaison avec la vue structure et la vue comportement.

• La vue comportement inclut les classes : comportement, état et transitions. Cette vue est

attachée à la structure.

• La vue technologie décrit les technologies, le process de fabrication et le matériel utilisé.

• La vue représentation décrit la géométrie de la structure.


Principle of solution

0..*

0..*Technical Solution

realised by0..*

State Model

State

Transitionis activated by

is stopped byFunction

realised by

1..*

0..*

0..*0..*

Feature

0..*

0..*Composite Feature

Part

0..*Assembly

Product

0..*

Behaviour

0..*

GeometryFEM

Representation

Technology

Structure

0..*

Figure 3.3 - Le méta modèle Produit de MOKA [MOK99]

Le projet MOKA propose également un modèle de processus de conception. Ce modèle de

processus inclut des catégories de connaissances dynamiques, les connaissances sur les

tâches/activités, les buts et les stratégies adoptée. Le modèle de processus est présenté avec le

formalisme UML (Diagramme d’activité). Les parallélismes, les synchronisations et les

transitions y sont représentés. Celles-ci ont les attributs suivants : description, inputs, outputs,

contraintes, ressources. Ce modèle du processus est lié avec le modèle produit par

l’intermédiaire de ses attributs inputs et outputs.

3.1.6 Modèle pour la capitalisation et la réutilisation des connaissances

Y. Harani [HAR97] propose un modèle de produit pour la capitalisation de savoir-faire, et la

réutilisation des connaissances. Il s’appuie sur le principe de métamodélisation et a pour but

de représenter et regrouper toutes les informations définissant et caractérisant le produit dans

une même base de connaissance.

Le modèle est construit de façon à permettre la définition du produit à partir des spécifications

extraites du cahier des charges, l’enrichissement de cette description au fur et à mesure de la


progression du projet et enfin, la conversation de l’historique de conception pour une

consultation et/ou une réutilisation ultérieure. Ce modèle de produit s’appuie sur trois

concepts, le concept produit, le concept paramètre et le concept point de vue. Le concept

produit représente le point de départ de la conception avec la description initiale du produit et

avec la récupération des informations relatives à un produit déjà conçu. Ce concept supporte

l’ensemble des informations à conserver durant la conception et ultérieurement. Pour ce faire

il est relié aux concepts paramètre et point de vue. Le concept paramètre exprime tout les

grandeurs quantitatives, soit issues du cahier des charges, soit générées, déterminées ou

calculées durant la conception. Le concept point de vue permet une prise en compte des

différentes perceptions qu’ont les concepteurs du produit. Elle est exprimée

dans le modèle par niveaux de concrétisation du produit : une vue fonctionnelle, une vue

comportementale et une vue structurelle. Chaque point de vue est modélisé comme un graphe

hiérarchisé avec des liens (de composition, de spécialisation ou d’appartenance) entre les

nœuds. Des liens peuvent exister entre nœuds de graphes différents (association d’une

fonction à un composant structurel). Dans son modèle, Y. Harani introduit le lien avec la

notion de comportement, relié à la notion de fonction et à celle de structure, approche

s’inspirant des travaux de Rosenman [ROS94].

Y. Harani propose également un modèle de processus associé au modèle de produit. La

modélisation proposée s’appuie sur quatre concepts principaux (Figure3.4). Ce sont le

concept processus (description des différentes étapes de développement du produit en

identifiant les tâches et leur mode d’enchaînement), le concept tâche (de type élémentaire ou

composite permettant la représentation du déroulement des étapes composant le processus), le

concept état (concernant le produit, le processus et les tâches) et le concept ressource

(matériel ou humain). Un couplage entre le modèle de produit et le modèle de processus est

également proposé afin d’assurer la cohérence de l’approche proposée.


0,n

1,n

1,n

0,n

1,n

0,1

0,n0,n

1,n1,1

1,1

0,n

0,n

1,1

1,n1,1

1,n1,1

1,1

1,n

1,1

0,n

Processus de conceptionidnompréconditionsdate_débutdate_fin

Etatidnom

Opérateuridnomdescription

Tâcheidnomdescriptionpréconditionspostconditions

Transitionidnom Opérateur Enchainement

idnomdescription

Ressourcesidnomfonctionnalités

a pour déclencheur

a pour état

a pour opérateur

a pour tâche de départ

a pour tâches non structurées

a pour transition

a pour état de sortie

a en entrée de tâche a en sortie de tâche

fait intervenir

est composée de

Figure 3.4 - Modèle de processus proposé par Harani [HAR97]

3.2 Approches pour la modélisation multi-points de vue des produits

Nous allons à présent étudier les deux principales approches qui ont jusqu’alors été

utilisées pour la prise en compte des points de vue des acteurs de la conception et de la

fabrication : l’approche à modèle unique et l’approche multi-modèles [GHO01]. Nous allons

dans ce qui suit décrire ces deux approches.

3.2.1 Approche à modèle unique

L’objectif de cette approche consiste à créer un modèle unique consensuel à partir de

différents vues. Cette approche est utilisée dans les travaux actuels sur la représentation de

produits dans les systèmes de CAO. A partir de cette représentation unique du modèle, chaque

expert va pouvoir interpréter son propre point de vue sur le produit. La figure 3.5 résume

cette approche.


Figure 3.5 - Représentation de l’approche à modèle unique

3.2.2 Approche multi-modèles

L’objectif de l’approche à multiples modèles est, contrairement à la précédente, de créer un

modèle unique pour chaque vue d’expert et d’établir des relations entre chacune de ces

entités. La gestion des relations entre les différentes représentations des experts impose

l’utilisation d’un ensemble de règle de cohérence qui doivent s’appliquer sur l’ensemble des

modèles. La figure 3.6 résume cette approche.

Figure 3.6 - Représentation de l’approche multi-modèles

Produit

MODELE UNIQUE

Expert Point de vue n°1



Interprétation Interprétation

Interprétation

…

Produit

REGLES DE COHERENCES



Expert Point de vue n°n

…

MODELE 1 MODELE 2 MODELE n


3.4.3 Avantages et inconvénients des deux approches

Le principal intérêt de l’approche à modèle unique réside dans le fait qu’il y a un modèle

unique à gérer, ce qui permet une gestion facile de l’échange et le partage de l’information.

Cependant, elle conduit à une représentation statique et fixe du produit car les modèles

manipulés par les différents experts sont fixés une fois pour toutes et ne varient pas en même

temps que la représentation du produit.

Par contre, l’approche Multi-Modèles permet aux experts de travailler de manière individuelle

avec les modèles qui leur conviennent le mieux tout en étant informés des avancées des autres

experts. Cependant, si le travail des experts est privilégié grâce à un ensemble de modèles

adaptés à leurs besoins, le maintien de la cohérence entre ces modèles ainsi que le partage et

le transfert d’information sont beaucoup plus difficiles à assurer. Le problème de la cohérence

est atténué par l’utilisation de règles de cohérence, mais leur identification et leur

formalisation reste difficiles.

4. Vers une approche Globale

Les modèles et approches présentés dans la section 3.1, ont tous des objectifs particuliers de

pouvoir supporter l’information concernant le produit et de la faire partager entre différents

acteurs. En effet, ces modèles et approches proposent des éléments intéressants pour notre

problématique mais aucun n’assure une complétude permettant de résoudre tous les points de

la problématique. Ils possèdent cependant un ensemble de règles d’évolution permettant

d’aboutir à une modélisation de plus en plus détaillée.

Une première critique qui peut être faite à ces modèles est qu’ils ne prennent pas en compte la

notion de Projet. Le fait que le concept de projet n’apparaisse pas dans ces modèles, empêche

la gestion du retour d’expérience, le suivi de projet et la construction de l’historique de la

conception.

Ces modèles souffrent également de l’absence d’un formalisme de modélisation normalisée

tel que EXPRESS facilitant leur échange et leur partage.


Une autre critique faite à ces modèles est qu’ils ne prennent pas en compte la notion de point

de vue, sauf pour le modèle d’Harani. Mais on a remarqué que ces points de vue sont limités

uniquement aux points de vue structurels, fonctionnels et comportementaux. Mais en aucun

cas les points de vue sur les projets.

Nous allons donc nous inspirer des recherches citées précédemment, pour proposer un cadre

méthodologique pour la représentation des points de vue des acteurs participants au

développement du produit.

Avec la proposition de UMEDA et son approche FBS, nous avons un premier pas vers la

définition des modèles liés aux points de vue des acteurs. En effet la méthode FBS permet la

description du produit à différent niveaux d’abstraction (Besoin, Fonction, Comportement,

Structure). Ces modèles seront regroupés dans le modèle de Produit. Mais le lien avec la

fabrication reste absent. Nous allons devoir proposer un modèle de Processus permettant de

décrire le processus de fabrication du produit.

Pour les approches et modèles concernant cette fois-ci la notion de point de vue, l’approche

Multi-Modèles est destinées ces dernières années à se développer, mais les difficultés qu’elle

engendre au niveau de l’échange et du partage de l’information nous ont paru trop

pénalisants.

L’approche envisagée consiste donc à permettre à chaque expert d’exprimer ses points de vue

d’une manière normalisée, à l’aide du formalisme EXPRESS de la norme STEP. Ce qui va

permettre d’un coté de faciliter l’échange et le partage de l’information et d’un autre coté

l’intégration et la représentation des points de vue métiers tout au long du cycle de

développement du produit. Pour la construction du modèle de Produit, qui regroupe

l’ensemble des modèles liés aux points de vue des acteurs, nous allons nous baser sur la

méthode FBS. Un modèle de Processus pour la fabrication sera proposé ainsi que son

couplage avec le modèle de Produit.


5. Conclusion

Dans ce chapitre, nous avons précisé la problématique de notre travail et présenté l’approche

envisagée pour résoudre les difficultés liées à la prise en compte de l’ensemble des points de

vue des acteurs lors d’un développement collaboratif de produit.

Le cadre méthodologique proposé doit reposer comme nous l’avons décrit précédemment

sur :

• Un modèle de Produit permettant de représenter les points de vue des acteurs à

différents niveaux d’abstraction,

• Un modèle de Processus permettant de décrire le processus de fabrication du Produit,

• Un formalisme capable de représenter les informations d’un produit d’une façon

normalisée afin de faciliter leur échange et leur partage.

En terme de formalisme de modélisation, notre choix s’est focalisé sur le langage EXPRESS

pour les raisons exposés dans le chapitre 2. En terme de méthodologie pour la construction du

modèle de Produit, nous allons nous baser sur la méthode FBS. Un couplage entre le modèle

de Produit et le modèle de Processus sera proposé afin d’assurer la cohérence entre la

conception et la fabrication.

Deuxième Partie

Méthodologie et Mise en Œuvre Informatique

Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 67

Chapitre 4

Méthodologie pour la modélisation intégrée Produit-Processus

1. Introduction

Dans le chapitre précédent, nous avons précisé la problématique et nous avons présenté

l’approche envisagée pour y répondre. Cette approche sera basée sur la méthode FBS pour la

construction des modèles liés au points de vue des acteurs, ainsi que le formalisme EXPRESS

de STEP pour une modélisation normalisée afin de faciliter l’échange et le partage de ces

modèles.

L’objectif de ce chapitre est de présenter la méthodologie proposée pour modéliser les divers

points de vue des experts de la conception et de la fabrication. Dans la première partie de ce

chapitre, nous présentons les éléments constitutifs de la méthodologie proposée. Cette

méthodologie sera menée selon deux axes : l’axe Produit et l’axe Processus, regroupant

respectivement les informations et points de vue métier sur le produit ainsi que son processus

de fabrication. Dans la deuxième partie, pour chaque modèle de Produit et de Processus, nous

présentons une description globale des concepts liés ainsi que leur modélisation. Nous


terminerons ce chapitre avec un exemple d’instanciation des modèles présentés pour un

connecteur électrique.

2. Eléments de construction de la méthodologie

Rappelons le fait que les acteurs travaillant simultanément au développement de produit sont

nombreux et de spécialités très différentes : client, commercial, concepteur, fabricant, etc. Les

points de vue qu’ils portent sur le produit sont également très différents.

Pour un développement efficace et dans le contexte d’Ingénierie Simultanée et d’Entreprise

Virtuelle, il est nécessaire de prendre en compte les différents points de vue. Un exemple de

cela est la coopération des experts de la fabrication au moment de la conception du produit

pour prendre en charge l’ensemble des problèmes relatifs à la fabrication du produit, qui

n’interviendra que beaucoup plus tard.

L’approche choisie comme nous l’avons décrite dans le chapitre 3, consiste à permettre à

chaque acteur de représenter ses points de vue durant les phases de conception et de

fabrication de manière normalisée, à l’aide du formalisme EXPRESS de la norme STEP, ce

qui va permettre d’un côté de faciliter l’échange et le partage de l’information et d’un autre

côté l’intégration et la représentation des connaissances métiers tout au long du cycle de

développement du produit [KHAb].

Pour mieux déterminer l’ensemble de modèles liés aux points de vue des experts, nous nous

sommes basés sur la méthode FBS. En effet, la démarche que l’on propose s’appuie sur un

ensemble de modèles susceptibles de prendre en compte les connaissances métiers dès les

premières phases du projet (Expression des besoins), et par un enrichissement progressif

(Fonction, Comportement, Structure) jusqu’à la définition complète du produit. Nous nous

appuyons également sur un modèle de processus pour la fabrication. Ainsi, la méthodologie

proposée sera menée selon deux axes : l’axe Produit regroupant les concepts : Besoin,

Fonction, Comportement et Structure, et l’axe Processus décrivant les informations liées aux

activités de la fabrication.


La première étape est la définition des besoins à partir du cahier de charges du client. Le

besoin représente le pourquoi du produit à concevoir. Par exemple, « connaître l’heure »,

lorsque cela est nécessaire, est devenu un besoin pour l’homme et pour cela, on a créé la

montre. Le terme « connaître l’heure » répond au pourquoi de la montre. Ensuite il faut

analyser ces besoins pour en déduire l’ensemble des fonctions qui vont caractériser le produit.

Ces fonctions seront décomposées en sous-fonctions possibles. A partir de cet ensemble de

fonctions et de sous-fonctions, les concepteurs proposent des comportements. Un

comportement permet la réalisation d’un ou plusieurs fonctions. L’étape suivante consiste à

construire à partir du modèle du comportement, le modèle de structure, ce modèle décrit les

lois physiques et les composants qui correspondent au produit. Le modèle de structure peut

être en relation avec un ensemble d’autres modèles qui sont le modèle géométrique, le modèle

de matériaux, le modèle de tolérance, et le modèle de processus de fabrication.

La figure 4.1 représente les étapes de construction des modèles liés aux points de vue des

experts, elle montre aussi comment à partir du Besoin on arrive au Processus de Fabrication,

et comment de ce dernier on peut remonter vers le besoin initial:

Figure 4.1 - Etapes de construction des modèles liés aux points de vue

CONCEPTION Exprimé par Exprime Effectué par Effectué Réalisé par Réalise

Besoin

Fonction

Comportement

Structure (Géométrie,

Tolérance, ..)

FABRICATION

Processus

Couplage


En général, la différence entre objet, fonction, comportement et structure n’est pas facile à

percevoir. Elle a été illustrée par [ROS94] dans l’exemple de la conception d’un ascenseur

comme le montre la figure 4.2.

Figure 4.2 - Représentation des définitions de Besoin, Fonction, Comportement et Structure

La conception d’un ascenseur vient du besoin de transporter des personnes ou marchandises,

mais d’une façon verticale. Alors, la fonction du système mécanique est de fournir ce

déplacement vertical. Il est possible de trouver plusieurs façons de faire cela. La définition du

comportement représente ces différentes manières de réaliser cette fonction. Dans notre

exemple, nous pouvons réaliser cette fonction, soit par une force qui tire la charge, soit par

une qui pousse la charge. En accord avec ces deux comportements, nous pouvons définir deux

structures différentes. L’une qui utilise un système à traction et l’autre qui utilise un système

ascendant hydraulique. Les composants de ces deux structures sont très différents. Par

COMPORTEMENT Tirer la charge FONCTION Déplacer pour au-dessus

COMPORTEMENT Pousser la charge FONCTION Déplacer pour au-dessus

BESOIN Déplacer personnes ou marchandise

ASCENSEUR A TRACTION STRUCTURE Moteur électrique , Câble Contrepoids…

ASCENSEUR HIDRAULIC STRUCTURE Colonne d’huile, piston …


exemple, pour l’ascenseur à traction nous trouvons des équipements tels qu’un moteur

électrique, câble, etc., tandis que pour l’ascenseur hydraulique nous trouvons des pistons,

réservoir d’huile, etc.

3. Description des Modèles

3.1 Modèle de Produit

Le modèle de Produit est destiné à représenter et à regrouper les points de vue des acteurs et

toutes les informations définissant et caractérisant le produit conçu ou à concevoir dans une

même base de connaissances. En effet, ce modèle est structuré de façon à pouvoir : (1)

identifier les fonctions du produit en extrayant du cahier de charges toutes les informations

relatives aux besoins des acteurs, (2) spécifier un comportement pour chaque fonction, (3) et

enfin, définir la structure du produit à partir du comportement. La figure 4.3 représente

l’ensemble des modèles et concepts liés au modèle de Produit.

Figure 4.3 – Modèle de Produit

S[a :b] Ensemble d’au moins a et d’au plus b élémentsLabel Entité Relation d’association


Dans un premier lieu nous donnons une vision globale de chaque modèle et nous donnerons

ensuite les définitions détaillées pour les modèles de base (Besoin, Fonction, Comportement,

Structure). Nous avons utilisé le langage EXPRESS-G pour notre modélisation. Rappelons

que EXPRESS-G est la notation graphique du langage EXPRESS.

Pour une entreprise qui conduit plusieurs projets de développement de produit, il est

nécessaire de les distinguer. Le modèle Projet réalise ce but. Au même temps qu’il sépare les

projets, il réunit plusieurs points de vue de tous les experts participants à ce projet. Le modèle

RelationP permet d’inter-relier les projets entre eux ou découper un grand projet en autres.

Le modèle Projet va permettre la capture de tous les points de vue sur un projet donné. Il va

permettre par la suite de rédiger un compte-rendu du projet. Ce compte rendu contient par

exemple la traçabilité des choix réalisés et les retours d’expérience relatifs au projet terminé.

Le modèle de Point-de-Vue définit le groupe d’acteurs d’une discipline. Il permet de

distinguer les informations de chaque métier. Il donne aussi à une équipe d’experts la

possibilité d’accéder aux points de vue d’une autre équipe pour obtenir des informations ou

même pour évaluer les solutions voire réaliser des propositions. Les attributs associés à ce

modèle sont : Nom et Description. L’attribut Nom représente l’acteur donnant son point de

vue, et l’attribut description représente le point de vue de l’acteur concerné.

Le modèle RelationBF représente la liaison entre les informations issues des modèles de

Besoin et de Fonction. Les deux autres modèles assurent la liaison entre les modèles de

Fonction et de Comportement, puis de Comportement et Structure. Ces liaisons entre modèles

de base (Besoin, fonction, etc.) sont importantes pour pouvoir vérifier dans tous les processus

de conception et de fabrication si le produit correspond bien aux besoins initiaux du client

avant d’en débuter la fabrication.

Nous détaillons ci-après les modèles de base (Besoin, Fonction, Comportement, Structure).


3.1.1 Modèle de Besoin

Le modèle de Besoin a pour objectif d’exprimer les besoins de chaque acteur participant au

développement du produit. La définition d’acteur est ici plus générique que d’habitude. Il peut

s’agir du Consommateur, Concepteur, Fabricant, etc. Ainsi, ce modèle va permettre de :

• s’assurer que le produit reste orienté vers les besoins des acteurs,

• assurer la vérification par la cohérence des besoins globaux,

• sauvegarder le savoir acquis par la création d’archives des besoins avec les fonctions

ayant été utilisées pour les satisfaire,

• créer une base de fait permettant de justifier les spécifications du produit (Fonction,

Comportement, Structure, etc) plus tard dans le processus de développement,

• hiérarchiser les besoins : besoins primaires, secondaires, etc,

• donner une importance relative aux besoins.

La figure 4.4 représente le modèle des besoins exprimé en langage EXPRESS-G. L’entité

Besoin est composée des entités ParamètreD’ingénierie, Relation-Besoin et des attributs Nom

et PoidsD’importance.

Figure 4.4 - Modèle de Besoin exprimé en EXPRESS-G


L’entité ParamètreD’ingénierie représente les valeurs imposées par le besoin. Les attributs

associés sont : (1) le Nom du paramètre, (2) le Type du paramètre (entier, réel, booléen,

alphabétique, etc), (3) la Nature du paramètre pouvant être électrique, mécanique, thermique

ou autres, (4) l’unité de mesure relative au paramètre, (5) l’Intervalle de valeurs spécifiant les

bornes minimales et maximales des valeurs que le paramètre peut avoir. Un exemple

illustratif d’une définition de paramètre est donné par le tableau 4.1 :

Nom Puissance du moteur

Type Entier

Nature électrique

Unité KW

Intervalle-valeurs [4 110]

Tableau 4.1 - Définition partielle d’un paramètre d’un moteur électrique

Enfin, l’entité Relation-Besoin définit la relation de décomposition Père-Fils entre les besoins.

Ci-dessous, nous avons représenté le modèle de Besoin selon le langage EXPRESS :

TYPE Nature = STRING; END_TYPE; -- STRING TYPE Unité = STRING; END_TYPE; -- STRING TYPE Type = STRING; END_TYPE; -- STRING ENTITY Besoin; Paramètre_D'ingénierie : SET [ 1 : ?] OF ParamètreD'ingénierie; Nom : STRING; PoidsD'Importance : STRING; END_ENTITY; -- Besoin ENTITY Paramètre D'ingénierie; Type : Type ;

Nature : Nature; Unité : Unité; Nom_Paramètre : STRING; Intervalle_Valeurs : STRING; END_ENTITY; -- ParamètreD'ingénierie ENTITY Relation-Besoin; Fils : Besoin; Père : Besoin; END_ENTITY; -- Relation-Besoin


3.1.2 Modèle Fonctionnel

C’est à cette étape que l’on doit se poser la question « Comment ? » pour la première fois. En

effet, on va ici réfléchir sur la façon de satisfaire les besoins exprimés dans le modèle de

Besoin. Pour satisfaire à un besoin, on définira une ou plusieurs fonctions.

En général, un concepteur détermine d’abord la fonction ou les fonctions principales du futur

produit. Puis, il décompose les fonctions en sous-fonctions jusqu'à la description complète du

produit selon cette vue. Le processus de décomposition produit un réseau de fonctions.

Ensuite, si l’on se situe dans le cas d’une conception « routinière » (modification ou

adaptation d’une solution existante à un besoin particulier), le concepteur utilise un catalogue

pour sélectionner l’élément fonctionnel le plus adéquat (un composant ou un ensemble de

composants) pour la réalisation adéquate de chaque sous-fonction. A partir de là, on obtient

une solution déduite de ces éléments sélectionnés.

Nous suggérons l’ordre suivant de construction de ce modèle:

(a) Spécification des fonctions,

(b) Décomposition des fonctions en sous-fonctions,

(c) Mise en place des conditions de réalisation (qualification des contraintes),

(d) Mise en place des contraintes.

Notre modèle représente le réseau des fonctions en montrant comment la relation Père-Fils

entre fonctions. Il est conçu pour permettre ensuite une analyse pour vérifier la consistance

des relations entre les fonctions. Par exemple, une lampe a comme fonction père de fournir la

lumière. Pour la réalisation de cette fonction, il faut arriver à une sous-fonction qui est

d’établir le contact. Si l’utilisateur du système oublie de prévoir cette dernière fonction, il

devrait être averti qu’il manque une sous-fonction nécessaire. Un autre point important est

que ce modèle permet de représenter les contraintes d’une fonction. Un exemple est le relais

d’une machine qui a pour fonction le chargement d’une batterie. Si le chargement dépasse 12

V, le relais intervient en l’arrêtant. La sous-fonction d’arrêt de la machine devra être

représentée par une entité qui sera explicitée ensuite.


La figure 4.5 montre en langage EXPRESS-G notre modèle fonctionnel. L’entité Fonction est

composée des entités Condition-de-Réalisation, Contrainte, Relation-Fonctions et l’attribut

Nom.

L’entité Condition-de-Réalisation est composée de l’attribut Nom qui représentera la

condition de réalisation qui sera utilisée pour en faire l’analyse postérieure. L’entité

Contrainte est composée de l’attribut Nom qui représentera les restrictions des fonctions. Et

finalement l’entité Relation-Fonctions définira la relation Père et fils des fonctions.

Figure 4.5 - Représentation du Modèle Fonctionnel en utilisant le langage EXPRESS-G

Ci-dessous, le modèle fonctionnel exprimé en langage EXPRESS.

ENTITY Fonction; Nom : STRING; Liste_Cond : SET [ 1 : ? ] OF Condition_de_Réalisation; Liste_Cont : SET [ 1 : ? ] OF Contrainte; END_ENTITY; -- Fonction ENTITY Condition_de_Réalisation; Nom : STRING; END_ENTITY; -- Condition_de_Réalisation ENTITY Contrainte; Nom : STRING; END_ENTITY; -- Contrainte ENTITY Relation fonctions; Fils : Fonction; Père : Fonction; END_ENTITY; -- Relationfonctions


3.1.3 Modèle Comportement

Ce modèle décrit les manières de faire ou réaliser une fonction. Une illustration en a été

donnée par le cas de l’ascenseur, figure 4.2.

Figure 4.6 - Modèle de Comportement représenté par le langage EXPRESS_G.

La figure 4.6 illustre ce modèle. L’entité Comportement est composée de l’attribut Nom qui

représente la manière de réaliser une fonction. Dans le cas de l’ascenseur (Figure 4.2) nous

pouvons définir pour la fonction « Déplacement vertical » les comportements « Tirer » ou

« Pousser ».

L’entité Relation-Comportement définit le lien entre les comportements. En effet, Un

comportement peut avoir une relation de père ou de fils d’un autre comportement.

Ci-dessous, le modèle de Comportement exprimé en langage EXPRESS.

ENTITY Comportement; Nom : STRING; END_ENTITY; -- Comportement ENTITY Relation Comportement; Père : Comportement; Fils : Comportement; END_ENTITY; -- RelationComportement


3.1.4 Modèle de Structure

Ce modèle, important pour les concepteurs, représente la description physique du produit.

Cela veut dire que la forme ou géométrie, les composants, la taille de chaque sous-ensemble

ou pièce, le produit assemblé ou désassemblé montrant chaque caractéristique, les tolérances

des parties mécaniques, les modes de fixation (souder, viser, river etc.) et les différents types

de matériaux qui constituent le produit, vont être tous représentés de manière précise dans ce

modèle.

Nous avons directement utilisé les modèles de la norme STEP pour représenter le modèle de

structure. Un produit est défini dans le modèle de données de STEP comme « une chose ou

substance élaborée par un processus naturel ou artificiel » [ISO94c]. Chaque pièce ou

assemblage qui contribue à un produit est aussi considéré comme un produit. Une voiture est

un produit, ses roues et assemblages du moteur sont considérés comme d’autres produits.

Chacun de ces produits peut être décomposé en produits (composants ou sous ensemble).

La figure 4.7 donne une vue du modèle de données de produit STEP. A cause du nombre

important des entités définies dans chaque partie de STEP, nous n’y avons représenté que les

entités les plus importantes.

L’entité product représente le produit dans STEP. Les attributs de cette entité définissent

l’identificateur, nom, description textuelle et la discipline (domaine) de l’application de

produit.

Comme la forme et la fonction du produit changent dans le temps, chaque version ou

historique du produit doit être décrite et doit être traçable dans le modèle. L’instance de

l’entité version de produit product_version est utilisée pour décrire l’évolution du produit

dans le temps (traçabilité de la conception).

Pour représenter les connexions entre le produit et les informations liées au produit, comme

assemblage, tolérance et représentation de la forme, etc., les entités Product-definition et


product-definition-relationship sont définies. L’entité product-definition-relationship peut

être utilisée pour représenter la relation d’assemblage. Cette entité a deux attributs related et

relating. Le produit référencé par relating représente l’assemblage et le produit référencé par

related définit un élément d’assemblage, par exemple : voiture (relating) et moteur (related).

Figure 4.7 - Modèle de structure exprimé en EXPRESS-G


Le modèle de produit doit être capable de décrire le produit pendant tout son cycle de vie.

L’entité Product-définition permet de caractériser une version particulière de la définition

d’un produit par rapport à un contexte applicatif. Un produit peut avoir plusieurs définitions :

une définition dans un contexte de conception fonctionnelle, une autre définition dans un

contexte de conception détaillée, etc. A cet effet, cette entité référence un contexte de

définition de produit dans une position donnée dans le cycle de vie du produit.

Les produits peuvent appartenir à des catégories spécifiques de produits. L’entité product-

category représente le type de catégorie d’un produit et l’entité product-category-relationship

permet de définir des liens entre différentes catégories de produit.

La configuration des relations dans un produit ou entre différents produits n’est pas suffisante

pour représenter la structure complète de produit. D’autres représentations comme la

géométrie, les tolérances, les matériaux, la cinématique sont nécessaire. L’une des

représentations qui est nécessaire et essentielle pour l’analyse d’ingénierie est la

représentation de la forme du produit.

Dans la figure 4.7, nous avons montré la relation entre la structure de produit et les

représentations de la forme de produit. Cette vue est extraite de la partie 41 (description de

produit) [ISOc94], la partie 43 (structures de représentation) [ISOd94] [ISOe94] et la partie

42 (représentation de géométrie et topologie) des documents de STEP.

L’entité shape_definition_representation établit la relation entre le produit et sa représentation

de forme. Cette entité permet l’indépendance entre la structure de produit et sa représentation

de forme, ce qui permet d’avoir de multiples représentations de la forme pour un produit.

Product_definition_shape est utilisé pour identifier chaque instance de product_definition.

L’entité representation référence les entités de base de géométrie ou les modèles

géométriques. Les représentations peuvent être organisées en relation avec les autres formes

au travers de l’entité representation_relationship. Par exemple, un arbre et un roulement

peuvent être géométriquement liés.


La définition de la forme dans STEP peut être utilisée pour décrire les informations de

produits comme traitement de surface et tolérance. Par exemple l’entité shape-aspect dénote

l’apparence géométrique de produit. L’information de tolérance est représentée par une entité

DT_shape_aspect qui est une sous-classe de shape_aspect.

Cependant, la représentation de l’assemblage de produit proposée dans le modèle de structure,

est insuffisante pour le fabricant. En effet, la connaissance du métier de fabricant est

fortement influencée par les caractéristiques de l’assemblage. Un modèle de structure doit de

permettre une représentation détaillée de l’assemblage d’un produit afin que le fabricant

puisse déterminer parallèlement le processus de fabrication et en analyser sa faisabilité. Ainsi,

la qualité de la conception se voit améliorée, et le temps de développement du produit réduit.

Nous avons constaté que les liaisons physiques entre les différents composants entrant dans

l’assemblage d’un produit ne sont pas prises en compte dans le modèle de structure de STEP

présenté au-dessous. Il n’y a pas en particulier de représentation des liaisons entre les features

géométriques des composants. Une entité ou feature est la forme géométrique pour laquelle

un processus de fabrication est connu. La notion de feature est une forme naturelle de

communication entre le concepteur et le fabricant, c’est le point commun de rapprochement

entre les modèles de description de la structure du produit (travail du concepteur) et les

modèles de préparation à la fabrication (travail du fabricant). Il existe plusieurs types d’entités

dans la littérature (entité de peau, entité squelette, entité d’assemblage, entité topologique,

entité d’usinage, etc) [GAM98]. C’est l’entité d’assemblage que nous considérons dans cette

partie de l’étude. La modélisation des assemblages par entités consiste à représenter

l’assemblage sous la forme d’une géométrie en prenant compte les relations spatiales

existantes entre les composants.

Plusieurs travaux de recherches menés par STEP dans le domaine de la modélisation

d’assemblage de Produit, sont en cours de validation [ISO01]. Mais à l’heure actuelle aucun

d’eux n’a été normalisé. Nous nous inspirons de ces recherches, pour proposer un modèle

d’assemblage qui va permettre de représenter les différents composants entrants dans


l’assemblage d’un produit ainsi que leurs liaisons physiques et géométriques, et en assurant la

cohérence avec le modèle de structure.

Ces travaux ont tout d’abord commencé par proposer une nouvelle représentation

hiérarchique de la structure d’un Produit. En effet, un Produit assemblé (assembly) est

composé de nombreuses pièces (parts), parfois regroupés en sous-ensembles (Sub-Assembly),

ce qu’illustre la figure 4.8.

Figure 4.8 - Structure hiérarchique d’un Produit assemblé

Afin de représenter cette nouvelle structure hiérarchique dans STEP, trois nouvelles entités

ont été créés. Ces trois entités représentées dans la figure 4.9 sont : (1) Assembly_definition

qui représente le produit assemblé (assembly), (2) Sub_assembly_definition qui représente les

sous-ensembles du produit assemblé, (3) piece_part_definition représente les pièces du

produit assemblé. Ces trois entités sont des sous-types de l’entité Product_Definition

présentée dans le modèle de structure (Figure 4.7).

Le lien entre assembly_definition, sub_assembly_definition et piece_part_definition est

représenté par l’entité next_assembly_usage_occurrence (sous-type de

product_defintion_relationship). En effet, cette entité représente le lien entre un produit

assemblé, ses sous-ensembles et ses pièces.

Produit assemblé

Sous-Ensemble Pièce

Sous-EnsemblePièce

PiècePièce

….


Figure 4.9 - Modèle d’Assemblage exprimé en EXPRESS-G

Afin de représenter les différentes liaisons physiques entre un couple de composants, L’entité

component_association, (sous-type de Product_definition_relationship) a été définie. L’entité

component_association exprime à travers l’entité component_association_relationship la

liaison physique entre deux composants (component 1 et component 2). La nature ou le type

de la liaison entre les deux composants sont représentés par l’entité connection.

Pour représenter la liaison entre les features géométriques de deux composants, nous avons

défini l’entité assembly_feature_association (sous-type de l’entité shape_aspect). En effet


l’entité assembly_feature va permettre à travers l’entité

Assembly_feature_association_relationship d’associer à deux composants (composant1 et

composant2) ces deux features géométriques (feature 1 et feature2 ). L’entité connection peut

là aussi être utilisé pour déterminer la nature de la liaison entre les deux features (Fixe,

Intermittent, etc).

3.2 Modèle de Processus

Bien que le concept de processus soit partagé par tous les spécialistes, sa définition, sa

typologie et sa description varient d’un domaine à l’autre (informaticiens, automaticiens,

gestionnaires, etc.). Le paragraphe suivant identifie trois types de processus de base des

entreprises et en donne une définition.

3.2.1 Types de processus en entreprise

[DEN95] distinguent trois types de processus : les processus matériels ("material processes")

(également appelés processus physiques), les processus informationnels ("information

processes" ) et les processus métiers ("business processes") :

1. Les processus matériels : ces processus se caractérisent par la manipulation, l'assemblage,

la livraison, la transformation, la mesure et le stockage d'objets physiques. Les processus

matériels lient entre elles des activités humaines ou automatisées, localisées dans le

monde physique. Il ne s'agit donc pas d'activités administratives, intellectuelles ou

spirituelle (quoique l'on puisse se poser la question de savoir si l'activité de rédaction d'un

livre est plutôt une activité intellectuelle ou une activité matérielle puisqu'elle a pour

conséquence immédiate la production d'un document physique). Pour [DEN95], la mise

en œuvre d'un processus matériel doit nécessairement aboutir à la production d'objets

physiques.

2. Les processus informationnels : les processus informationnels relient entre elles des

activités automatisées (exécutée par des programmes) ou semi-automatisée (accomplies

par des humains en interaction avec des programmes). Ces activités créent, traitent, gèrent

et fournissent de l'information. L'infrastructure de base des processus informationnels est


fournie par les systèmes d'information de l'entreprise, tels les Systèmes de Gestion de

Bases de Données, les systèmes de gestion de transaction, etc.

3. Les processus métiers : Selon [SHE96] et [DAV90], un processus métier est une

collection d'activités consommant des entrées (matériels, finances, données,...) et délivrant

un ou plusieurs résultats à orientation économique ("business result") ou à forte valeur

ajoutée pour l'entreprise. Un processus métier représente la façon dont un travail est

réalisé plutôt que l'organisation des personnes et des services, traversant les barrières

hiérarchiques et structurelles de l'entreprise. Pour [GEO95], les processus métiers se

situent à un niveau conceptuel plus élevé que les deux types précédents de processus de

part leur orientation économique. Par suite, un processus métier peut mettre en œuvre

d'autres processus, de type informationnel et/ou matériel, si leur réalisation permet

d'atteindre l'objectif qui est associé au processus métier. L'expression de "processus

métier" est l'une des nombreuses traductions de "business process" que l'on peut

rencontrer dans la littérature francophone. D'autres traductions possibles et intéressantes

sont par exemple "processus opérationnel", proposée par Vernadat [VER99], processus

d'entreprise, que l'on retrouve dans le lexique de la Workflow Management Coalition

(WfMC) [WFM99] ou encore "processus stratégique", que l'on retrouve dans [ZAR97b].

Remarquons que pour F. Vernadat, la notion de processus opérationnel adopte un sens

plus global et concerne tout processus d'intérêt pour l'entreprise. Néanmoins l'expression

"processus métier", employée entre autres dans la revue "Le Monde Informatique" nous

semble convenir le mieux. En effet, l'expression "processus métier" indique que le

processus en question est directement lié au métier de l'entreprise qui le met en œuvre. Par

métier on comprend l'ensemble des compétences d'une entreprise, son domaine d'activité,

qui se traduisent par l'offre d'un ensemble de services, produits ou artefacts, dont la

consommation par des clients lui permet de se pérenniser et de se développer.

Les processus auxquels on s’intéresse correspondent aux processus de fabrication qui peuvent

toutefois être rapprochés aux processus matériels. Pour modéliser ces processus, nous nous

inspirons ainsi de la littérature de modélisation et d’intégration d’entreprise, fort riche des

développements qui ont été menés dans divers projets nationaux [GZA00], européens et

internationaux (CIMOSA) mais aussi de plusieurs travaux normatifs menées par le CEN


(Comité Européen de Normalisation) et l’ISO (International Standard Organisation). Dans la

section suivante, nous étudions les différents concepts liés à la modélisation d’un processus.

3.2.2 Définition du concept de Processus

Plusieurs définitions du concept de processus ont été proposées. Nous étudions dans ce qui

suit certaines d’entre elles.

En terme de travaux normatifs, l’ISO définit un processus comme « Un ensemble de moyens

(personnels, équipements, méthodes, etc.) et d’activités liées qui transforment des éléments

entrants (inputs) en éléments sortants (outputs), tout en créant de la valeur ajoutée ».

[HAM93] rejoint cette définition en présentant le processus comme « une suite d’activités qui,

à partir d’une ou de plusieurs entrées, produit un résultat représentant une valeur pour le

client ».

[HAR91] précise qu’un processus désigne toute activité ou groupe d’activités qui prend une

entrée, lui ajoute de la valeur et fournit une sortie à un client interne ou externe. Par ailleurs,

un processus utilise des ressources de l’organisation pour fournir des résultats définitifs.

[LOR97] présente un processus comme un ensemble d’activités reliées entre elles par des flux

d’information ou de matière, qui se combinent pour fournir un produit matériel ou immatériel

important et bien défini.

Ces définitions se rejoignent ainsi sur la définition du processus comme un ensemble

d’activités liées qui transforment, à l’aide de ressources des éléments entrants en éléments

sortants pour créer de la valeur ajoutée.


En considérant la définition de [ELM97] qui présente un processus comme « une

combinaison d’activités mobilisant des savoir-faire multiples se déroulant dans le temps et

étant finalisé par un objectif , une notion supplémentaire d’objectif, est alors introduite.

L’objectif est la raison d’être de l’activité. Cette notion d’objectif se retrouve également dans

la définition proposée par [VER99] où un processus est une succession de tâches qui

contribuent à la réalisation des objectifs de l’entreprise. Il précise par ailleurs que de manière

générale, un processus peut être défini comme un enchaînement d’activités à exécuter pour

atteindre un objectif donné. Cet enchaînement forme ce qu’il est convenu d’appeler le flux de

contrôle du processus, c’est à dire sa logique d’exécution.

Ainsi, aux caractéristiques précédemment dégagées pour le processus, s’ajoute la notion

d’objectif d’un processus qui correspond à un résultat à atteindre.

Dans la suite de cette section nous détaillons les principales caractéristiques d’un processus

que nous venons d’identifier, à savoir les notions de composants du processus (les activités,

les entrants et sortants, les ressources, etc.)

3.2.3 Les composants du processus

3.2.3.1 L’activité

Toutes les définitions présentées précédemment s’appuient sur le concept d’activité comme

élément de décomposition de processus. Or, Il arrive souvent dans la littérature, que les

auteurs emploient le terme tâche au lieu d’activité. Le sens de ce mot est souvent dépendant

du contexte ou il est employé et de sa compréhension par l’auteur. Certains spécialistes

appellent « tâche » tout élément d’un processus qui représente un travail ou un ensemble de

travaux. Ainsi, une tâche peut être une activité (telle que nous l’avons définie), un processus

étant alors composé de tâches.

D’autres personnes utilisent indifféremment tâche et activité pour désigner le même concept.

Si l’on souhaite approfondir le terme, il est possible de définir la tâche comme étant un travail

affecté à une ressource, dont la réalisation est en général au moins soumis à une contrainte


temporelle. La réalisation d’une tâche permet d’atteindre un objectif. Le travail permettant de

réaliser la tâche est alors appelé activité.

Ainsi, nous considérons qu’un processus est composé d’activités. Une activité peut être par

ailleurs soit décomposable et elle se décompose alors en d’autres activités, soit élémentaire.

Ce dernier cas correspond à ce qui est souvent appelé opération.

Dans les définitions de processus étudiées précédemment, les relations entre les activités d’un

processus ont été souvent exprimées dans des termes du type : enchaînement (partiellement

ordonné) d’activités, chaîne d’activités, séquence d’opérations, ensemble d’activités, suite

d’activités, etc. [MEN93] distingue trois types de relations entre les activités :

• Relation de succession (les sorties d’une activité sont nécessaires pour qu’une autre

activité se réalise),

• Partage de ressources (deux ou plusieurs activités utilisent les mêmes ressources et

l’exploitation des Ressources par l’une peut influencer la performance de l’autre),

• Simulanéité (les sorties de deux ou plusieurs activités sont nécessaires pour réaliser les

activités suivantes dans le même processus).

Nous nous intéressons en particulier à étudier les relations de succession c’est à dire à

l’enchaînement des activités. Cet enchaînement existe à cause des flux matériels ou

informationnels (désignés généralement par les termes d’input-outputs ou entrées-sorties).

Si certains auteurs considèrent que l’enchaînement des activités est prédéfini (processus

déterministe), d’autres proposent une typologie de processus selon le caractère prédéterminé

ou non de l’enchaînement de ses activités, Ainsi dans [GZA00], on distingue :


• Les processus structurés : caractérisés par une connaissance quasi-parfaite à la fois de

l’ensemble des activités qui la composent et de leur enchaînement. L’objectif du

processus est parfaitement défini. C’est des processus automatisables.

• Les processus semi-structurés et non-structurés : caractérisés par une connaissance

imparfaite de l’enchaînement des activités. Deux cas se présente :

- Lorsque l’objectif du processus est connu à priori et est parfaitement défini, on parle

de processus semi-structuré. Dans ce cas, le cheminement menant à l’objectif est

déterminé à fur et à mesure du déroulement du processus. C’est un processus où

l’homme prend des décisions sur le choix des activités (parmi un portefeuille

d’activités) et de leur enchaînement et ce selon le résultat, imprévisible, de la phase

précédente.

- Lorsque l’objectif n’est pas connu à priori, on parle de processus non structuré. Dans

ce cas, l’ensemble des activités qui le composent n’est pas également connu.

L’objectif se construit alors progressivement au cours du déroulement du processus et

donc nécessite la création ou le développement d’activités à fur et à mesure aussi.

L’homme prend des décisions sur la détermination de l’objectif et le choix du

cheminement pour atteindre l’objectif (les activités qui permettent de l’atteindre) ainsi

que les capacités à mobiliser.

Pour notre modèle, l’enchaînement des activités sera décrit par des relations de précédence,

deux cas se présentent :

• Une activité a un suivant, ce cas correspond à une séquence d’activités,

• Une activité a plusieurs suivants, ce cas correspond à une activités dont les suivants

peuvent se faire en parallèle.

Par ailleurs, les Activités seront associées à des conditions de transition qui permettront de

conditionner leur enchaînement. Un processus a également une activité de départ qu’il est

important d’identifier. En effet, c’est l’activité de départ qui va lancer le déroulement du

processus.


3.2.3.2 Les entrants / sortants d’un processus

Les entrants/sortants d’un processus sont les objets sur lesquels agit l’activité pour réaliser

son objectif. La réalisation d’une activité consiste donc à transformer un élément d’entrée en

élément de sortie sous certaines conditions. On parle souvent de condition de transition

(transition condition). Une condition de transition est le critère régissant la progression ou le

changement d’état d’une activité ou le passage à l’activité suivante.

Une condition peut figurer avant ou après une activité ou un ensemble d’activités. Dans le

premier cas, il s’agira d’une précondition. Une précondition représentera la condition de

départ. Dans le second cas, il s’agira d’une postcondition. Une postcondition peut être

occasionnée par l’exécution d’une activité afin d’être prises en compte pour le bon

déroulement de l’exécution des activités suivantes.

3.2.3.3 Les Ressources

Les ressources représentent l’ensemble des intervenants lors du déroulement du processus

qu’ils soient humains, ou matériels (Machines, Applications Informatiques).

Notons qu’en terme de ressources humaines, GZARA [GZA00] parle plutôt d’acteurs que des

personnes physiques. Un acteur correspond à un profil particulier de personnes physiques

dans l’entreprise. Ainsi plusieurs personnes physiques peuvent correspondre au même acteur.

A titre d’exemple, un chef de bureau d’étude, un méthodiste, un responsable de ligne sont des

acteurs différents. Cette façon d’organiser les ressources humaines garantit une stabilité de la

modélisation des processus concernés en évitant de redéfinir les ressources d’un processus à

chaque changement de fonction des personnes physiques.

Une notion de rôle est rattachée au fonctionnement des ressources. Cette notion est essentielle

car une même ressource peut intervenir dans le processus selon différents rôles en fonction de

l’activité considérée.


3.2.3.4 L’état

Ajoutons également le concept Etat. Tout au long de l’exécution des divers processus

rattachés au produit, celui-ci change d’état au fur et à mesure de l’exécution des différentes

activités et décisions prises lors de ces processus.

3.2.3.5 Synthèse

La figure 4.10 modélise l’ensemble des concepts et des relations inter-concepts utilisés pour

modéliser le processus.

Figure 4.10 - Modèle de Processus exprimé en EXPRESS-G

L’entité Processus est composée des attributs : Nom, Activité_Départ, et Etat_Processus.

L’attribut Nom représente le nom du processus. L’attribut Activité_Départ représente

l’activité qui déclenche le début du processus. L’attribut Etat_Procesus permet de suivre

l’évolution du processus dans le temps.

L’entité Activité est composée des attributs : Nom, Objectif, activité_suivante, et

activité_composite. L’attribut Nom représente le nom de l’activité, l’attribut objectif

représente la raison d’être de l’activité ou la tâche à réaliser. L’attribut activité_suivante

spécifie quelle est l’activité associée à une activité pour définir la suite de l’agencement du

processus. Enfin l’attribut activité_composite traduit le lien entre une activité décomposable

et les activités qui la composent.


L’entité Ressource représente les ressources nécessaires pour exécuter une activité. Il peut

s’agir comme on l’a vu plus haut d’une ressource humaine ou de ressources matérielles. Les

attributs de l’entité Ressources sont les suivants : le Nom de la Ressource, les Fonctionnalités

traduisant la liste des services que la ressource présente et met à disposition du processus, le

rôle qui représente les fonctions d’une ressource dans l’activité à laquelle elle participe et

enfin l’attribut Etat_Ressource permettant de spécifier si la ressource est libre, occupé dans

l’exécution d’une activité, etc.

L’entité Donnée représente les éléments Entrants/Sortants sur lesquels agit l’activité pour

réaliser son objectif. Enfin, l’entité Condition de Transition représente les contraintes et les

conditions qui permettent de passer d’une activité à l’autre.

Ci-dessous le modèle de processus exprimé en EXPRESS-G.

TYPE Etat = String; END_TYPE; -- String TYPE Rôle = STRING; END_TYPE; -- STRING ENTITY Activité; Ressource : SET [ 1 : ? ] OF Ressources; Nom : String; Objectif : String; Etat_Activité : Etat; END_ENTITY; -- Activité ENTITY Activité_Départ SUBTYPE OF ( Activité ); END_ENTITY; -- Activité_Départ ENTITY Processus; Etat_Processus : Etat; Nom : String; activité_départ : Activité_Départ; END_ENTITY; -- Processus ENTITY Ressources; rôle : SET [ 1 : ? ] OF Rôle; Etat_Ressource : Etat; Fonctionnalités : STRING; Nom : STRING; END_ENTITY; -- Ressources ENTITY activité_composite SUBTYPE OF ( Activité ); END_ENTITY; -- activité_composite ENTITY activité_suivante SUBTYPE OF ( Activité ); END_ENTITY; -- activité_suivante


3.3 Couplage entre le modèle de Produit et Processus

La connaissance liée au couple Produit-Processus, doit nécessairement être formalisée. En ce

qui concerne la formalisation de cette connaissance, elle semble pouvoir être supportée par le

modèle de structure, car par définition et comme on vient de le voir, le modèle de Structure

permet de représenter toutes les connaissances liées à la fabrication, comme par exemple, les

éléments d’entrées et sorties des activités, les informations de tolérance, les formes

géométriques (Features), l’assemblage, etc.

La figure 4.11 représente le lien entre le modèle de Produit et le Modèle de Processus. Ce lien

va permettre de construire une base de connaissances par la création d’archives de structures

de produit avec les processus ayant été utilisés pour les satisfaire tout au long du processus de

fabrication. Ce lien va permettre aussi d’assurer la cohérence entre la conception et la

fabrication.

Figure 4.11 – Couplage entre le modèle de Produit et de Processus

4. Exemple de développement d’un connecteur électrique.

L’exemple de développement d’un connecteur électrique va illustrer l’ensemble de modèles

précédemment présentés. L’exemple part de l’instant de la décision stratégique de constituer

le groupe de projet.

4.1 Constitution du groupe de projet

Ce sont les spécificités du produit à développer qui conditionnent la constitution du groupe de

projet. Deux démarches sont généralement utilisées.

La première consiste en la nomination d’un chef de projet qui va choisir alors son groupe de

projet. La deuxième démarche consiste à constituer le groupe projet. Le chef de projet ressort


de ce groupe. C’est généralement le cas dans des structures plus réduites et des projets de

petite taille où il est difficile d’extraire impérieusement des individus pour les mettre sur un

nouveau projet sans créer de déséquilibres dans les structures de l’entreprise.

Dans les deux cas il faut créer un groupe efficace qui présente toutes les garanties de succès

pour les objectifs visés. La démarche consiste :

• à lister les disciplines nécessaires au projet (en partant des objectifs),

• pour chacune de ces disciplines à lister les compétences nécessaires au projet,

• d’établir les critères de choix des membres du groupe de projet en tenant compte des

spécificités du projet,

• de faire les choix.

Chacune des compétences nécessaires au projet est donc sous la responsabilités d’un membre

du groupe et d’un seul. Ce qui ne veut pas dire que le membre du groupe a toutes les

compétences de sa responsabilité. Les membres du groupe ont été choisis en plus de la qualité

humaine de communication et de meneurs d’hommes, pour leurs compétences spécifiques à

ce projet là. Par ailleurs, c’est les membres du groupe de projet qui vont pouvoir exprimer

leurs points de vue tout au long du développement du produit.

Disciplines Compétences Membre responsable

Electricité - Transport du courant - Isolement - Polarisation - …

Monsieur X

Chef service électrique

Mécanique - Manipulabilité - Assemblage - Protection - …

Monsieur Y

Responsable études mécaniques

Traitement de signal - Résistance à l’abrasion - Revêtement - Cuivrage - …

Monsieur Z

Ingénieur spécialisé

Economie/Marketing/Vente - Logistique - Planning - Achat - …

Monsieur W

Responsable Marketing

Tableau 4.2 - Démarche de constitution du groupe de projet de développement du connecteur


Le tableau 4.2 illustre l’ensemble de disciplines, les compétences ainsi que les personnes

responsables qui ont été choisis pour le développement d’une nouvelle gamme d’un

connecteur électrique.

4.2 Instanciation du modèle de besoin

La figure 4.12 représente l’instance du modèle de Besoin selon les deux points de vue du

consommateur et du fabricant pour le même besoin. Nous pouvons voir que la manière de

considérer un même besoin par différentes personnes appartenant à différents domaines sont

distinguées.

Figure 4.12 – Instanciation du Modèle de Besoin par deux points de vue différents

Le consommateur est préoccupé par l’apparence du produit, la facilité de le transporter, de

l’installer et de le stocker, par son prix et sa performance. La vision du fabricant est tournée

vers la facilité de fabrication, le coût de fabrication, le budget pour le réaliser, la quantité à

produire, la géométrie (de préférence non complexe) et la fréquence de fabrication, sur toute

l’année ou une partie seulement.

Besoin de transmettre les signaux

Besoin du point de vue du consommateur Besoin du point de vue du fabricant

Performancedu Produit

Apparence Coût Interface avecL’Homme

PerformanceFonctionnelle

Contraintede dimension

Mécanique

Electrique

Taille Forme

AdaptationPhysique à

d’autres produits

Facile àRéparer

Facile àTransporter

Facile pourmagasiner

Facile àinstaller

SûretéBon agencementdu produit

Pièce légère

Facile àFabriquer

Quantité àfabriquer

Le temps /date pour

livrerproduit

Produit desaison

Productionfréquente

Créditdisponible

pour faire lafabrication

La manièred’assembler

Descriptiondu produit

La géométrie /La forme


4.3 Instanciation du modèle Fonctionnel

La figure 4.13 représente le modèle fonctionnel selon trois points de vue, celui du

mécanicien, de l’électricien et du thermicien. Ce modèle va permettre d’identifier par exemple

à partir d’un besoin initial (Fournir une jonction électrique démontable), l’ensemble des

fonctions et sous fonctions du Produit à concevoir La fonction principale du Produit a été

donc décomposée en trois sous-fonctions : Mécanique, Electrique et Thermique. En

poursuivant la création du modèle, nous avons déterminé trois sous-fonctions pour la partie

mécanique (Protection Produit, Fixation, Manipulabilité), plus trois pour la partie électrique

(Protection Electrique, Conduite Electrique, Protection Electromagnétique). Et enfin, une

sous-fonction pour la partie thermique (Eviter l’échauffement).

Figure 4.13 – Instanciation du Modèle Fonctionnel et son lien avec le modèle de Besoin

Si nous affinons encore le modèle, nous pouvons trouver encore plus de sous-fonctions. Par

exemple, nous pouvons découper la fonction manipulabilité en Préhension et Adhérence

Manuelle. Préhension représente la facilité de saisir et de manipuler le dispositif. Adhérence

Fournir une jonctionélectrique démontable

Conduiteélectrique

Protection électrique

FonctionElectrique

Protection électro-

magnétique

Isolation électrique

Protéger personnes

Limiter fuites

électriques

Protéger Produit

Fixer

Fonction Mécanique

Manipulabilité

Fixer le connecteur

sur la machine

Fixer le câble

Fixer les contacts

Eviter L’échauffement

Fonction Thermique

Besoin

Fonctions


Manuelle représente les parties de l’objet qui ont besoin d’une adhérence pour la réalisation

d’un but. Par exemple, l’écrou possède une forme extérieure qui facilite l’adhérence manuelle

permettant de le tourner facilement pour le verrouiller. La fonction Protection peut être

découpée en : Protection-Choc et Compression et Protection-Corrosion. La première a pour

fonction de protéger les composants du produit contre les chocs ou une compression

provenant de l’extérieur. La deuxième représente la protection contre la corrosion d’origine

interne ou externe. De cette manière il est possible de parvenir à un modèle complexe en

continuant la décomposition des fonctions. Plus complexe sera le modèle, meilleure sera la

représentation du produit final.

4.4 Instanciation du modèle de Comportement

A partir du modèle Fonctionnel, les experts vont pouvoir proposer des comportements. Ces

comportements vont leur permettre par la suite de définir les composants de la structure finale

du produit. La figure 4.14 représente l’ensemble des instances du modèle de comportement et

leurs liens avec les instances du modèle Fonctionnel.

Figure 4.14 – Instanciation du modèle de Comportement et son lien avec le modèle Fonctionnel

Conduiteélectrique


Fonction Electrique


magnétique


Protégerpersonnes

Limiter fuites

électriques

Protéger Produit

Fixer

Fonction Mécanique

Manipulabilité

Fixer le connecteur

sur la machine

Fixer le câble

Fixer les contacts

EviterL’échauffement

FonctionThermique

En assurantun contact

Mâle-Femelle

En choisissantdes matières

adéquates

En les maintenant avec une

matière en plastique

En serrant le câble avec un

serre câble

En fixant l’embasse avec des

vis

En couvrant le connecteur avec des matières

résistantes

En empêchant le contact avec les parties

électriques

En isolantles

contacts

Com

portements

Fonctions


4.5 Instanciation du modèle de Structure

Cette fois-ci, à partir des instances du modèle de comportement, le concepteur va pouvoir

définir les différents composants de la structure du produit. La figure 4.15 représente les

différents composants définis à partir des différents comportements.

Figure 4.15 – Instanciation du modèle de Structure et son lien avec le modèle de Comportement

Enfin, à partir de l’ensemble de composants définis dans le modèle de structure, le concepteur

va pouvoir instancier le modèle d’assemblage du produit final, ainsi que les liaisons physiques

et géométriques entre les différents composants, ce qu’illustre la figure 4.16.

Avant de passer à la fabrication finale du produit, le fabricant va devoir en premier lieu

analyser et vérifier la faisabilité du produit. Le fabricant doit veiller à ce que le produit reste

faisable au fur et à mesure que la définition de la structure et l’assemblage du produit

avancent. Le fabricant devra donner ces points de vue au concepteur afin que ce dernier

puisse les prendre en compte.

En assurant un contact

Mâle-Femelle

En choisissant des matières

adéquates




serre câble


vis


résistantes


électriques

En isolant les

contacts

Boitier

Contact Mâle

Porte Contact Mâle et Femelle

Contact Femelle

Serre câble

Embase avec des

trous pour vis

Coquille

Plaquette

Structure C

omportem

ents


Components_association Assembly_feature_1 Assembly_feature_association Assembly_feature2

1 Cylindre Fixe Trou 2 Vice Vissage Ecrou 3 Prisme Intermittent Prisme 4 Prisme Fixe Prisme 5 Cylindre Fixe Trou 6 Trou Fixe Cylindre 7 Trou Intermittent Cylindre 8 Prisme Fixe Prisme 9 Prisme Fixe Prisme

10 Prisme Fixe Prisme 11 Prisme Fixe Prisme

Figure 4.16 – Instanciation du modèle d’assemblage

Connecteur (assembly)

Embasse (sub-ass1)

Fiche (sub-ass2)

Bloc Contact F (sub-ass3)

Corps Embasse (part1)

Isolant (part3) Contact F

(part4)

Ecrou (part2)

Bloc Contact M(sub-ass3)

Boîtier de Fiche

(sub-ass4)

Serre Câble

(sub-ass5)

Isolant(part5)

Contact M(part6)

Douille (part7)

Coquille Ecrou

(part10)

Coquille Couverture

(part11)

Plaquette(part12)

Presse Câble (part8)

Passe Câble (part9)

1

6

2

5

3 4

9

10

11

87

NAU NAU

NAU NAU

NAU

NAU

NAU NAU

Assembly_feature_association

Feature1 Feature1


La figure 4.17 résume l’ensemble d’instances des Modèles (Besoin, Fonction, Comportement,

Structure) ainsi que leurs liens.

Figure 4.17 - Vue générique sur les instances et liaisons entre modèles

Fournir une jonctionélectrique démontable

Conduiteélectrique


Fonction Electrique


magnétique


Protéger personnes

Limiter fuites

électriques

Protéger Produit

Fixer

Fonction Mécanique

Verrouiller Mâle-

Fermelle

Fixer le connecteur

sur la machine

Fixer le câble

Fixer les contacts

Eviter L’échauffement

Fonction Thermique

En assurant un contact

Mâle-Femelle

En choisissant des matières

adéquates




serre câble


vis


résistantes


électriques

En isolant les

contacts

Boitier

Contact Femelle

Porte Contact Mâle et

Femelle

Contact Mâle

Serre câble

Embase avec des

trous pour vis

Coquille

Plaquette

Besoin

Structure

Com

portements

Fonctions


4.6 Instanciation du modèle de Procesus

Nous avons défini dans la section 3.3 un modèle de processus pour représenter le processus de

fabrication du produit. Nous allons utiliser ce modèle pour représenter la séquence

d’assemblage du connecteur électrique.

Une séquence d’assemblage peut être définie comme une suite d’activités à réaliser pour

obtenir le produit fini. Le connecteur électrique possède 9 activités d’assemblage représentées

dans la figure 4.18. Ces activités sont exécutées par des ressources matériels ou humaines.

C’est l’activité de départ (Assembler Embasse) qui déclenche le déroulement du processus.

Les activités (Assembler Embasse, Assembler Serre-Câble, Assembler Bloc Contact M) sont

décomposables. La figure 4.18 illustre le lien entre ces activités décomposables et les activités

qui les composent.

Chaque activité possède des éléments d’entrées, pour notre cas ce sont les différents

composants du connecteur électrique. Ces entrées sont transformées à la fin de l’activité et

donnent un élément de sortie. Par exemple les composants ou les entrées (Isolant et Contact

F) de l’activité (Assembler bloc Contact F) donnent en sortie le Bloc Contact F.

En ce qui concerne le déclenchement des transitions entre les activités, elles ne sont pas

déclenchées par des événements externes mais c’est la fin de l’activité précédente qui

déclenche la transition et fait démarrer l’activité suivante. En d’autres termes, l’événement est

la fin de l’activité suivante. Lorsqu’il s’agit de transitions gardées par des conditions de

transition, c’est la condition de condition qui valide la transition et la déclenche.


Figure 4.18 – Instanciation du modèle de Processus (Séquence d’assemblage)

ProcessusAssemblageConnecteur

AssemblerEmbasse

AssemblerSerre-Câble

AssemblerBloc Contact M

Assembler(Coquille Ecrou+Serre-Câble)

Assembler(Coquille Ecrou+Serre-Câble)+Bloc Contact M

Assembler(Coquille Ecrou+Serre-Câble+Bloc

Contact M)+Ecrou


Contact M+Ecrou)+Plaquette


Contact M+Ecrou+Plaquette+Coquille couverture)+Embasse

Assembler BlocContact F

(Isolant+ContactF)

Assembler (BlocContact F+

Corps Embasse)

Activité Départ

Activité Suivante

Activité Suivante

Activité Suivante

Activité Suivante

Activité Suivante

Activité Suivante

ActivitéSuivante

ActivitéComposite

Assembler(Isolant+ContactM)

Assembler(Isolant+Contact

M)+Douille

ActivitéSuivante

ActivitéComposite

Activité Suivante

Activité Suivante

COM

COM

CoquilleCouverture

Plaquette

CoquilleEcrou

Douille

Fiche

ContactMâle

Bloc Contact Mâle

Assembler (PresseCâble+ Passe

Câble)COM

ActivitéComposite

PRODUIT FINAL

Isolant Contact F

Entrées

Entrées

Isolant Contact M

Sortie : Bloc Contact F

Assembler(Coquille Ecrou+Serre-Câble+Bloc ContactM+Ecrou+Plaquette)+ Coquille couverture


5. Conclusion

Dans ce chapitre, nous avons présenté une méthodologie pour modéliser les divers points de

vue des acteurs de la conception et de la fabrication. Cette méthodologie se repose sur :

• Un modèle de produit permettant de décrire les différents facettes du produit à concevoir à

différents niveaux d'abstraction (Besoin, Fonction, Comportement, Structure),

• Un modèle de Processus permettant de décrire le processus de fabrication du produit à

différents niveau de détail.

Le principal objectif poursuivit par ces deux modèles est la capitalisation des connaissances

métiers tout au long de la conception et de la fabrication. L’apport essentiel de notre travail

réside, d’une part, dans l’intégration du modèle de Produit et du modèle de Processus et,

d’autre part, par le fait que ces modèles soient généraux et génériques. La généralité qu’ils

véhiculent est due au fait qu’ils ne soient, à la base relatifs à aucun domaine d’application

existant comme le cas de STEP. Ainsi, ils peuvent être adaptés pour servir de support à la

représentation de la connaissance métier de n’importe quel produit. Quant à leur généricité,

elle est relative à la possibilité de spécialiser les modèles par domaine d’application des

produits à concevoir. D’ou la possibilité de procéder à une réutilisation des connaissances

pour une nouvelle conception, ce qui garantirait une réduction de temps.

Cette étude a permis de résoudre certains problèmes liés au développement collaboratif de

produit. La suite de l’étude consistera à développer un système informatique support à la

modélisation entre l’ensemble des acteurs afin de faciliter l’échange et le partage des modèles

dans le contexte de l’Entreprise Virtuelle, c’est l’objectif du chapitre suivant.

Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 104

Chapitre 5

Infrastructure pour la modélisation, l’échange et le partage des données de produit

1. Introduction

Comme on l’a déjà vu dans les chapitres précédents, la complexité de la conception et du

développement intégré des produits manufacturés, imposant une participation de plus en plus

forte d’acteurs aux compétences variées et souvent répartis sur des sites géographiquement

éloignées, rend aujourd’hui nécessaire l’élaboration d’infrastructures de communication

supportant le concept dorénavant d’Entreprise Virtuelle. Ces infrastructures doivent autant

que possible s’appuyer sur les Nouvelles Technologies d’Information et de Communication et

les Normes Standards d’échange et de partage de données de produit.

L’objectif de ce chapitre est de définir une infrastructure pour la modélisation, l’échange et le

partage de données de produit. Dans la première partie, nous justifions la nécessité de cette

infrastructure, et nous identifions les besoins organisationnels et technologiques auxquels elle

doit répondre. La deuxième partie sera consacré au choix d’une architecture pour cette

infrastructure. Dans la troisième partie, nous vous présentons les éléments constitutifs de


l’Infrastructure proposée ainsi que leurs fonctionnalités. Avant de conclure, nous vous

présentons un scénario de démonstration.

2. Nécessité d’une infrastructure

Pendant les différentes phases du cycle de vie d’un produit, un grand nombre d‘informations

sont utilisées et manipulées par différents acteurs. L’exploitation de ces informations pose des

problèmes de communication tels que l’accès, l’échange et le partage de ces informations

entre des sites distants et entre des systèmes hétérogènes bien souvent incompatibles.

Actuellement les concepteurs disposent de peu d’outils informatiques leur permettant d’être

assistés dans les échanges d’informations. En effet, les informations sont véhiculées dans des

fichiers qui sont stockées dans des bases de données locales. Lorsqu’un concepteur veut

transmettre une information à un autre, il utilise la messagerie ou le téléphone. Lorsqu’une

modification intervient, le concepteur doit se rappeler du circuit de validation de cette

information pour la faire circuler. Ceci pose principalement des problèmes d’erreurs dans la

transmission des informations, de pertes de temps pour réussir à joindre un acteur et de risque

d’oubli de destinataires pour la validation. A tous ces constats, se rajoute la dimension

« éclatée » et « multi-sites » des équipes de conception due, de nos jours, aux fréquents

regroupements et fusions d’entreprises comme l’Entreprise Virtuelle. Se rajoute également la

dimension « multi-projet » des informations de produit.

Cela signifie concrètement qu’une infrastructure doit être mise en place. Une infrastructure

représente la plate-forme technologique dont une entreprise a besoin pour atteindre ses

objectifs et donner forme à sa vision. C’est la structure des éléments constitutifs d'un Système

d’Information, du point de vue matériel et logiciel.

Une Entreprise Virtuelle doit donc s’efforcer de définir une infrastructure informatique à

l’échelle de toute l’organisation. Jusqu'à période récente, ce n’était pas vraiment l’objectif

principal ou une préoccupation. Lorsqu’il était utilisé, le terme infrastructure avait un sens

plutôt restreint, il s’appliquait par exemple à la conception d’infrastructures répondant aux


besoins de chaque partenaire et non pas une seule infrastructure normalisée pour les différents

membres de l’E.V.

Pour la grande majorité des entreprises, il n’y avait pas d’infrastructure du tout, pas

d’organisation structurée des technologies de l’information et de communication

correspondant à une vision d’E.V. Tout au plus, l’infrastructure mise en œuvre représentait la

somme des divers systèmes informatiques mis en œuvre au fil des années pour faire face aux

besoins du moment. Il est désormais possible de planifier et de mettre sur pied une

infrastructure cohérente et évolutive à l’échelle de l’Entreprise Virtuelle fondée sur une vision

de ses besoins et de ses perspectives d’avenir.

Les Nouvelle Technologies de l’Information et de Communication, les Normes Standards

d’échange et de partage de données permettent à l’heure actuelle de définir une infrastructure

propre à l’Entreprise Virtuelle et indépendante de celles des partenaires. Une telle

infrastructure est destinée à répondre de manière rentable aux exigences globale de

l’Entreprise Virtuelle tout en offrant une plate-forme d’innovation conviviale pour toutes les

applications de l’informatique aux activités de l’entreprise.

Une conception nouvelle de l’infrastructure de l’Entreprise Virtuelle s’avère donc nécessaire

si l’on veut tirer profit des innovations technologiques actuelles. Notre objectif, est de définir

une infrastructure support à la modélisation, l’échange et le partage des données de Produit.

Cette infrastructure devra intégrer une application informatique d’aide à la modélisation et

une autre pour la gestion du stockage, l’échange et le partage des modèles et autres

informations de produit, l’ensemble, en une seule plate-forme informatique.

Nous décrivons ci-après, les besoins organisationnels et technologiques auxquels doit

répondre notre infrastructure.


2.1 Besoins organisationnels

Une Entreprise Virtuelle est un regroupement temporaire, c’est une organisation d’équipe.

C’est une structure adaptée au type d’action et à la nature de l’objectif à atteindre. C’est une

division du travail avec ses mécanismes de communication, de coordination et de

collaboration spécifiques.

Cette structure organisationnelle est simple et légère, flexible et réactive. Pour soutenir la

nature évolutive des affaires, l’infrastructure doit elle-même être flexible, adaptable et

dynamique :

• Flexible pour répondre rapidement aux conditions du marché dynamique,

• Adaptable aux restructurations organisationnelles,

• Dynamique pour pouvoir se reconfigurer en fonction des affaires.

A l’heure actuelle, et comme on l’a vu dans le chapitre 1, il existe trois types d’Entreprise

Virtuelle : 1) E.V court-terme, 2) E.V Consortium, 3) Entreprise Etendue. Le point de départ

est une E.V court-terme dans un marché opportuniste. Avec la stabilisation du partenariat,

cette E.V migre progressivement vers une E.V de type Consortium (marché dynamique). Une

E.V (soit court-terme ou soit de type Consortium) peut avoir une durée de vie plus longue si

ces membres forgent ensemble leurs qualités pour faire face à une opportunité du marché qui

grandit. Dans ce cas, l’E.V. migre encore vers une E.V de type étendue en stabilisant sa

structure.

Quoi qu’il en soit, le point de départ d’une E.V est en général une E.V court terme. Il faut

garder à l’esprit qu’une E.V est une organisation transitoire qui doit répondre aux besoins du

marché à un instant donné. Elle n’est que momentanée et de durée limitée. Notre

infrastructure doit considérer ses différents types et leurs évolutions structurelles.


Notre objectif serait donc la conception d’une infrastructure générique capable de s’adapter

avec n’importe quel type d’Entreprise Virtuelle.

2.2 Besoins Technologiques

Avant de définir l’infrastructure support à l’Entreprise Virtuelle, nous avons recensé et

détaillé les concepts et les caractéristiques technologiques qu’elle devra intégrer. Ceci inclut

l’utilisation des technologies de communication existantes comme Internet, ainsi que

l’intégration des Normes Standards d’échange et de partage de données comme STEP.

Notre infrastructure support à l’Entreprise Virtuelle devrait être basée sur 3 modules

principaux répondant à ses exigences technologiques comme le montre la figure 5.1. Les

besoins et les fonctionnalités de chaque module ainsi que sa solution technologique sont

présentés dans ce qui suit.

Figure 5.1 - Modules de l’Infrastructure Support à l’Entreprise Virtuelle

2.2.1 Plate-forme de communication

Les entreprises virtuelles ont besoin d’un ensemble de technologies de communication pour

partager des informations intra ou interentreprises et pour les échanger activement avec

d’autres entreprises via le réseau. Les services de réseaux avancés sont nécessaires pour

permettre aux acteurs de travailler comme s’ils étaient proches. La technologie Internet, avec

Plate-Forme de Communication

Solution pour

l’intéopérabilité

des modèles

Gestion de Stockage et Partage de Données


ses services principalement le WEB, répond à ce besoin de communication entre les membres

de l’Entreprise Virtuelle.

Le succès d’Internet vient du fait que c’est un outil complet et indispensable, avec une

disponibilité quasi universelle et une homogénéité technique. Ses qualités permettent aux

entreprises de se connecter entre elles, non seulement physiquement, mais également à tous

les niveaux de complexité des réseaux. Sans oublier les derniers progrès concernant l’Internet

Haut débit, avec l’apparition de nouveaux modes de connexion de plus en plus rapide comme

l’ADSL20.

Internet est une infrastructure mondiale d’interconnexion de réseau, qui peut être définie

comme une addition simple [CLO00] :

• Des outils et protocoles (SMTP, POP, IMAP4, TCP/IP,etc),

• Des utilisateurs (par dizaines de millions),

• Des services (messagerie électronique, Forum de Discussion, WEB, etc)

Une des principales qualités d’Internet, la « communication ouverte », apporte une grande

potentialité pour la valeur ajoutée d’une entreprise. Si les deux systèmes d’information sont

connectés via Internet, alors rien n’est nécessaire pour fournir une chaîne commune de

communications entre les deux systèmes. C’est un des avantages de TCP/IP, le protocole

utilisé pour Internet.

Le service phare d’Internet reste le WEB. C’est au CERN à Genève qu’est apparue vers 1989

l’idée puis la réalisation d’un système permettant d’accéder à des pages d’informations

textuelles (puis rapidement multimédia) reliées entre elles par des liens hypertextes [LEF98].

20 ADSL : Asymetric Digital Subscriber Line, technologie qui permet de disposer de débits de plusieurs Mbit/s sur des lignes de téléphone normales.


Sachant que ces pages étaient stockées sur des serveurs de réseau Internet, elles devenaient

accessibles à tous et donnaient lieu à une navigation entre serveurs en fonction des liens créés

dans les pages. On aboutissait donc à un système de serveurs de pages hypertextes multimédia

et distribuées permettant de naviguer (surfer dans le jargon Internet) de pages en pages sur un

serveur.

Le résultat fut ce que l’on a d’abord appelé le World Wide Web, puis W3 et maintenant le

Web (ou la toile) en référence à l’image de la toile d’araignée de connexions virtuelles qui

relient ces différents serveurs. Pour ce faire, il était nécessaire de définir plusieurs

fonctionnalités :

• Tout d’abord une manière pour un utilisateur de récupérer une page sur un serveur :

c’est le protocole HTTP qui définit ce mode d’accès,

• Ensuite, une codification de la mise en forme d’une page, que ce soit pour le texte, les

images ou les objets divers tels que le tableaux, et évidemment les liens hypertextes

vers les éventuelles autres pages. C’est le standard HTML qui détermine la manière de

créer une page,

• Enfin un mode d’adressage de chaque page accessible, d’où la notion d’URL, ou

adresse d’une page.

Sur la base de ces protocoles, la dernière brique indispensable concerne le logiciel client qui

appliquant ces protocoles, permet à l’utilisateur d’exploiter facilement les potentialités du

Web. Il s’agit du Navigateur ou Browser, et dont les exemples les plus connus sont désormais

Netscape Navigator et Internet Explorer de Microsoft. Le navigateur WEB constitue la partie

visible d’Internet. En effet, c’est lui qui se charge d’afficher l’information venant du serveur

WEB. Un navigateur est une application qui se compose généralement de quatre

parties distinctes :


• Un menu qui regroupe les fonctions classiques d’une application (la gestion du presse-

papier notamment), ainsi que le paramétrage de la connexion au réseau, diverses

options de personnalisations, etc.,

• Une barre d’outils qui permet surtout de naviguer et de retrouver les pages

précédemment visitées avec un bouton « Précédent » et un bouton « Suivant »,

d’imprimer la page en cours, etc.,

• Une barre d’adresse, partie essentielle, qui permet à l’utilisateur d’indiquer, sous

forme d’URL, l’adresse de la page qu’il veut voir affichée,

• Une zone client qui occupe toute la place restante et dans laquelle est affichée la page

WEB demandée.

Les possibilités du navigateur ont rapidement dépassé la simple fonction d’afficheur de pages

WEB [GOG99]. En sa faveur jouait aussi un argument de poids : puisque le contenu géré par

le navigateur était téléchargé dynamiquement du réseau au moment où l’utilisateur en avait

besoin, les coûts d’administration des postes pourraient s’en retrouver fortement réduits, et

comme les entreprises sont toujours ouvertes à la nouveauté lorsqu’on leur parle de faire des

économies, l’idée du client universel était née. Dorénavant, tout finirait inéluctablement par

s’exécuter dans un navigateur et plus personne ne se soucierait de disposer de tel système

d’exploitation plutôt que de tel autre.

Nous pouvons résumer l’apport des technologies de l’Internet en quelques points qui sont les

suivants :

• Réduction de la complexité et les coûts du système d’information de l’entreprise,

• Simplification de l’architecture technique dans le cas d’un déploiement pour un grand

nombre d’utilisateurs,

• Offre d’un point d’accès unique pour toutes les informations,

• Poste client léger et universel,

• Développement, déploiement, administration et extension simplifiés,


• Support et extension des investissements technologiques déjà engagés,

• Réduction des coûts d’exploitation du parc micro-informatique.

• Sécurité.

Même si la sécurité constitue encore pour l'instant sa faiblesse majeure, il est fort probable

qu'Internet offrira sous peu un niveau de sécurité relativement élevé. En effet, un "firewall"

couplé avec des applications conçues proprement offre un niveau de sécurité suffisant pour la

plupart des transactions [KAE00][GHE00].

Comme nous venons de le montrer, toutes les facilités pour le partage d'informations et la

communication au sein des équipes virtuelles peuvent être bâties sur les services de base

offerts par Internet et le Web.

2.2.2 Gestion de stockage et partage de données

Un autre module indispensable pour l’Entreprise Virtuelle est le module de gestion de

stockage et partage de données. Il sert à la gestion d’un ensemble de données stockées dans

un système informatique, structurées, organisées de façon à répondre rapidement, souvent

simultanément aux requêtes des utilisateurs de l’E.V.

Nous proposons la technologie d’Entrepôt de Données21. Un Entrepôt de données est une base

de données conçue pour stocker et partager en un endroit unique toutes les données provenant

de sources externes. Afin d’exploiter les données de l’Entrepôt, il faut fournir à l’utilisateur

une interface d’accès aux données.

La conception de cet entrepôt de données ainsi que son interface d’accès doivent obéir à un

petit nombre de règles précises :

21 Entrepôt de Données : Traduction de REPOSITORY, c’est la forme la plus sophistiquée des systèmes de bases de données.


• Manipulabilité : Des personnes ne connaissant pas l’entrepôt de données doivent être

capables de décrire leurs requêtes sans faire référence à des éléments techniques de la

base de données.

• Limitation de la redondance : L’interface d’accès doit pouvoir éviter dans la mesure

du possible des informations redondantes, afin d'éviter d'une part un gaspillage

d'espace mémoire mais aussi des erreurs.

• Partageabilité des données : L’interface d’accès doit permettre l'accès simultané aux

données par plusieurs utilisateurs.

• Sécurité des données : L’Entrepôt de données doit présenter des mécanismes

permettant de gérer les droits d'accès aux données selon les utilisateurs (module

d’administration).

• Historicité : L’entrepôt de données doit permettre de suivre l’évolution des données

dans le temps.

• Orientation Sujet : Les données de l’entrepôt doivent s’organiser par sujet. Cette

organisation permet de rassembler toutes les données pertinentes à un sujet, et

nécessaires aux besoins des membres de l’Entreprise Virtuelle.

• Rapidité des accès : Le système doit pouvoir fournir les réponses aux requêtes le plus

rapidement possible, cela implique l’utilisation de moteurs de recherche.

2.2.3 Solution pour l’interopérabilité des modèles

Pendant les différentes phases du cycle de vie d’un produit, un grand nombre d’informations

sont utilisées et manipulées par des intervenants distincts et souvent géographiquement

éloignés. L’exploitation de ces données pose des problèmes de communication tels que

l’accès, l’échange et le partage d’informations entre des sites distants et entre des systèmes

hétérogènes bien souvent incompatibles.

Pour surmonter ces problèmes, notre infrastructure va devoir adopter des Standards portant

sur la manière d'échanger des données ainsi que sur la structure des données échangées. Le

fonctionnement efficace des Entreprises Virtuelles est donc inimaginable sans l'acceptation et

la diffusion d'un ensemble de standards. En effet, même si les progrès des technologies de


communication rendent possible la communication de masses de données entre deux

entreprises en quelques secondes, l'exploitation des données reçues peut engendrer d'énormes

délais si des mesures pour assurer la compatibilité des communications et l'interopérabilité

des applications ne sont pas prises. Selon [HAR96], notre infrastructure devra également

respecter quelques points :

• Performance : la donnée nécessaire pour une opération peut, si elle est délivrée en

retard, causer un délai supplémentaire pour l’ensemble du système.

• Concurrence : la donnée délivrée doit uniquement contenir les informations

nécessaires afin de ne pas perturber le travail concourant d’autres acteurs de

l’Entreprise Virtuelle.

• Compréhension : le système qui reçoit la donnée doit être capable d’interpréter et de

traiter cette donnée.

Les Standards sont donc indispensables pour construire et faire évoluer un environnement

technologique cohérent et intégré, qui constitue l’ossature de l’Entreprise Virtuelle. Or les

normes standards sont nombreux. La norme la plus profitable pour notre infrastructure est la

norme STEP présentée dans le chapitre 2.

L’objectif de la norme STEP, est de fournir, à travers un ensemble de standards, une

représentation de l’information relative à n’importe quel stade du cycle de vie d’un produit,

par la définition de modèles de données uniques pour le produit qui pourront être échangés

entre tous les intervenants. Par ailleurs, notre infrastructure devra intégrer un outil

informatique permettant aux membres de l’Entreprise Virtuelle, de pouvoir créer leurs

modèles selon la norme STEP.

Synthèse :

Le tableau 5.1 résume nos choix technologiques correspondant aux 3 modules principaux sur

lesquels reposera notre infrastructure :


Modules de l’Infrastructure

Solution pour L’Interopérabilité

des modèles

Plate-Forme de communication

Gestion de stockage et partage de Données

Technologie choisie STEP Internet+WEB Entrepôt de Données

Tableau 5.1 – Modules et solutions technologiques de l’Infrastructure

Aujourd’hui, le Web n’est plus utilisé seulement pour la publication de documents, il devient

rapidement une interface graphique22 permettant l’accès aux bases de données sous un

environnement Client-Serveur. La prochaine partie sera consacrée à l’étude de l’architecture

Client-Serveur la plus performante pour notre infrastructure.

3. Choix d’une architecture

Toutes les architectures informatiques Client-Serveur présentent des caractéristiques

communes :

• elles intègrent une interface utilisateur, souvent graphique,

• elles fonctionnent, bien sûr, grâce à des applications,

• les applications qui les animent manipulent des données.

C’est la répartition de ces trois composantes entre le client et le serveur qui caractérise les

différentes architectures. Dans cette partie nous allons dans un premier temps nous attacher à

décrire les différentes architectures Client-Serveur, ensuite, nous ferons une comparaison afin

de comprendre le pourquoi d’une telle architecture pour notre infrastructure.

3.1 Architecture à 2 niveaux : Client lourd-Serveur

L'architecture à 2 niveau, appelée également architecture client lourd23, caractérise les

systèmes clients/serveurs dans lesquels un logiciel client complexe se connecte directement à

22 On parle souvent de DATAWEB. 23 Traduction de FAT CLIENT.


une base de données installée sur le serveur pour y récupérer les informations dont il a besoin

via des requêtes de type SQL (Figure 5.2).

Le problème principal de ce type d’architecture provient du coût élevé d’administration d’un

tel système décentralisé. L’évolution du système nécessite de ré-écrire le logiciel client, et de

le re-déployer sur l’ensemble des postes de l’entreprise [CLO00].

Figure 5.2 - Architecture Client-Serveur à 2 Niveaux

Le Client-Serveur tel qu’il est mis en œuvre sur le Web constitue le plus souvent une

évolution à trois niveaux du modèle à deux niveaux.

3.2 Architecture à 3 Niveaux : Client léger- Serveur WEB- Serveur de Données l’architecture à 3 niveaux, appelée également architecture client léger24 est constituée d’un

poste client, d’un serveur WEB ou Serveur d’Applications, et d’un serveur de base de

données comme illustré dans la figure 5.3.

L’idée est de fédérer l’accès aux applications sous une unique interface WEB, à savoir les

fameux Navigateurs [GOG99]. L’intérêt principal du Web repose entièrement sur sa facilité

de déploiement : pas de configuration côté client. Le Navigateur devient le client ultime, léger

et universel. Ce modèle est le plus puissant et le plus intéressant, il permet de développer des

interfaces homogènes indépendante du matériel et du système d’exploitation.

24 Traduction de THIN CLIENT.


Figure 5.3 - Architecture Client-Serveur à 3 Niveaux

Le premier niveau est constitué par l’interface utilisateur. C’est la vision du système

d’information pour les utilisateurs finaux. On parle de client léger, du fait qu’il ne gère que les

liens avec le serveur Web. Le terme « léger » s’oppose ainsi au concept du « client lourd » qui

nécessité beaucoup de ressources matérielles et logicielles pour fonctionner.

Le deuxième niveau est composé d’un serveur WEB ou serveur d’applications qui joue deux

rôles principaux : répondre aux requêtes des postes clients et animer le dialogue avec le

serveur de données du troisième niveau.

Le troisième niveau est composé des sources de données de l’entreprise au sein desquelles le

serveur Web va puiser. Ces sources de données peuvent être diverses puisqu’elles sont

constituées soit de bases de données relationnelles telles qu’Oracle, Microsoft SQL Server,

MySQL, soit d’applications existantes de l’entreprise (souvent supportées par des systèmes

mainframes), soit de progiciels intégrés (SAP, Baan).

La complexité potentielle de cette approche réside donc dans la manière d’accéder à ces

différentes sources de données. Soit il existe des connecteurs ou des passerelles offrant la


même interface vers ces sources de données, soit il n’en existe pas, auquel cas le

développement des interfaces vers ces données peut s’avérer complexe et coûteux.

3.3 Comparaison des deux types d’architecture

L'architecture à deux niveaux est donc une architecture client/serveur dans laquelle la logique

applicative se trouve partagée entre le client et le serveur. Mais dès que les concepteurs ou les

administrateurs du système éprouvent le besoin de l'étendre sur des entreprises éloignées

géographiquement, cette architecture paraît beaucoup moins pratique. Il est difficile de

déployer et d'administrer une architecture orientée client, car cela nécessite souvent le

déplacement de personnel compétent et la refonte de tout le système.

L’autre inconvénient de l’architecture à 2 niveaux touche la performance du réseau. En effet,

les requêtes SQL des utilisateurs sont traitées par le SGBD sur le serveur, or les résultats des

requêtes peuvent être très volumineux ce qui génère des problèmes d’engorgement de réseau,

et ce surtout s’il y a beaucoup de postes de travail en ligne.

Dans l'architecture à trois niveaux par contre, les tâches sont délocalisées. Le client WEB

assure la présentation des données, tandis que la logique d’application est centralisée dans une

application sur le serveur WEB. Cette dernière est elle-même la partie cliente d’un échange

client serveur avec un SGBD déporté. Cette architecture à trois niveaux bien distincts permet

de bien séparer chacune des fonctions et autorise une mise à jour de l’application sur le

serveur uniquement, le navigateur étant désormais un client de présentation banalisé.

L’administration est donc re-centralisée. Nous vous résumons les avantages de l’architecture à

trois niveaux :

• Mise à jour simple et rapide des postes : Les applications sont centralisées sur les

serveurs. La mise à jour des postes clients peut être faite de façon globale à partir du

Serveur en une opération unique.

• Une plus grande Sécurité : Toute information, qu’elle soit sous la forme de données

ou d’applications, réside sur le serveur. Protéger le réseau se limite donc uniquement à

protéger le serveur. Il est bien entendu plus aisé de protéger un point unique du réseau


(le serveur) que chaque point du réseau (les postes clients). Les droits de chaque

utilisateur étant définis par l’administrateur, le contrôle des données et des

applications s’en trouve renforcé.

• Réduction des coûts d’administration et de formation : L’application n’étant plus sur

le poste client, les coûts d’exploitation sont plus réduits. Avec un client universel,

c’est moins de formation pour les utilisateurs. D’autant plus que ces derniers sont de

plus en plus habitués à l’ergonomie des navigateurs de l’Internet. La formation sera

davantage centrée sur l’application et ses fonctionnalités que sur l’interface elle même.

• Meilleur performance du réseau : Ne circulant sur le réseau que les données

correspondant au résultat exact de ce qui aura été demandé par les utilisateurs, la

performance du réseau serait optimisée.

L’architecture à trois niveaux est donc l’architecture la plus performante pour notre

infrastructure.

4. Architecture de l’Infrastructure proposée

La figure 5.4 représente l’architecture de l’infrastructure proposée pour la modélisation, le

stockage et le partage des données de l’Entreprise Virtuelle [KHAc][KHAd]. Cette

architecture reflète un effort d’intégration des technologies de communication

(Internet+WEB) et les normes d’échange et de partage de données (STEP). L’intégration de

cet ensemble de technologies en une seule infrastructure est susceptible d’offrir de nouvelles

opportunités capable d’enrichir la collaboration entre les membres de l’Entreprise Virtuelle.

Comme on peut le constater sur la figure 5.4, c’est une architecture à 3 Niveaux. Cette

architecture à trois niveaux bien distincts, permet comme on l’a vu précédemment une

meilleur performance et une mise à jour de l’application sur le serveur Web uniquement. Le

navigateur étant désormais un client de présentation banalisé. Cette architecture est également

facile à mettre en œuvre pour n’importe quel type d’Entreprise Virtuelle.


Figure 5.4 - Architecture de l’infrastructure support à l’Entreprise Virtuelle

Notre architecture support à l’Entreprise Virtuelle se fond sur 3 piliers :

• Le réseau Internet et ses services qui va nous servir d’infrastructure de base,

• Un outil d’aide à la modélisation STEP,

• Une application pour la gestion de stockage et de partage des données de l’entrepôt.

Les membres de l’Entreprise Virtuelle vont pouvoir créer leurs modèles de produit grâce à

l’outil d’aide à la modélisation EXPRESS-G Modeler (EGM). Les utilisateurs vont pouvoir

stocker et partager l’ensemble des données de produit dans l’entrepôt de données par

l’intermédiaire d’une Interface d’Accès aux Données de Produit (IADP). Ces deux

applications sont accessibles par un Navigateur.

Entreprise A

Entreprise B

Entreprise C

Entrepôt de Données

Données provenant des

Entreprises A,B,C

Serveur WEB

Client Léger

Pare-feu

Niveau 1 Niveau 2 Niveau 3

Navigateur - EGM - IADP

Internet


Toute la logique applicative des deux applications (EGM et IADP) est centralisée sur le

Serveur Web. Ce dernier est lui même la partie cliente d’un échange Client-Serveur avec un

Entrepôt de Données déporté. Cette gestion déportée de données dans laquelle l’utilisateur

accède directement aux données de l’entrepôt est assurée par le langage de script (PHP).

Pour la sécurité, nous avons choisi la solution de pare-feu (Firewall). Le pare-feu a pour

vocation de protéger notre infrastructure des attaques externes. Il s’agit d’une solution

logicielle fonctionnant sur le serveur WEB, et joue le rôle de contrôleur d’accès. Il rejette les

tentatives de connexion non autorisées au réseau interne et traduit les adresses des postes du

réseau interne, les rendant invisibles à Internet, ce qui interdit à un intrus de pénétrer sur le

réseau interne. En outre, le pare-feu peut être paramétré pour permettre à des appels venant

d’Internet de se raccorder au réseau interne sous réserve d’authentification par filtrage de leur

adresse IP. Il suffit pour cela d’indiquer au pare-feu les coordonnées d’authentification des

appelants éventuels, filiales, clients ou fournisseurs.

Nous vous détaillons dans ce qui suit, les deux applications principales de cette infrastructure,

à savoir EXPRESS-G Modeler (EGM) et l’Interface d’accès aux Données de Produit (IADP).

4.1 EXPRESS-G Modeler

Rappelons que pendant les différentes phases du cycle de vie d’un produit, des informations

sont utilisées et manipulées par des intervenants distincts et souvent éloignés, utilisant des

systèmes et machines hétérogènes. Au cours de l’exploitation de ces informations, se posent

plusieurs problèmes de communication. Nous pouvons citer le problème de l’incompatibilité

des modèles de données.

Pour y répondre, le projet STEP a introduit le langage EXPESS. Son objectif principal est la

représentation non ambiguë de modèles de produit, interprétable par tout système

informatique , en vue d’un échange facile et fiable entre les différents intervenants.


A cet effet, nous avons développé un outil graphique d’aide à la modélisation basée sur la

norme STEP. Cet outil va permettre aux acteurs de l’Entreprise Virtuelle de créer des modèles

EXPRESS-G et de les convertir en modèles EXPRESS. Rappelons que le langage EXPRESS-

G est la notation graphique du langage EXPRESS.

EXPRESS-G Modeler (EGM) a été développé à l’aide du langage Java. Nous avons choisi le

langage Java pour satisfaire aux exigences de portabilité et de facilité de développement.

4.1.1 Le Langage JAVA

Issu d’un projet de recherche lancé par Sun en 1990, Java est un langage de programmation

orienté objet, au même titre que C++ ou Smalltalk, pour ne pas citer que les plus utilisés. Sa

syntaxe est très proche de celle de C++, tandis que sa simplicité, la grande quantité de

composants intégrés au langage, et ses principes fondamentaux le rapprochent plutôt de

Smalltalk [TAS00].

A l’origine Java était destiné à l’informatique embarquée 25(cartes à puces, imprimantes, etc.),

mais le succès d’Internet a très tôt provoqué sa réorientation. Son excellente portabilité

permet à un programme Java compilé d’être exécuté sur n’importe quelle-forme. Le mot

d’ordre de Sun pour Java est d’ailleurs write once, run anywhere26.

C’est en 1996, que Sun livre le premier JDK (Java Developement Kit). Il s’agit d’un

ensemble d’outils que l’on peut télécharger gratuitement sur Internet, comprenant un

compilateur, un débogueur, des API très riches, etc. En somme, tout ce dont un développeur a

besoin pour produire rapidement un programme Java complet.

25 Aujourd’hui, cela devient effectivement le cas avec KJava (Java simplifié pour terminaux bancaires, Palm Pilots, etc.), mais aussi JavaCard pour les cartes à Puces, JavaPhone, JavaTv, etc. 26 Développer une fois, exécuter n’importe ou.


En ce qui concerne la portabilité du langage Java, on peut en distinguer deux niveaux : celle

du code source et celle de l’exécutable. La portabilité du code source représente la possibilité

pour un développeur d’écrire le code d’un programme sans avoir à se soucier de

l’environnement précis dans lequel il sera exécuté. Ceci lui évite d’avoir à écrire plusieurs fois

le même programme selon qu’il souhaite l’exécuter sous Windows ou Unix, par exemple.

Un autre problème d’envergure est la portabilité des exécutables [FLA01]. Quel que soit le

langage de programmation, le code source écrit par le développeur n’est pas intelligible

directement par une machine : il faut d’abord traduire ce code source en code machine. Cela

peut se faire une fois pour toutes (c’est ce qu’on appelle la compilation) ou bien au moment

de l’exécution, grâce à un interpréteur qui lit le code source et exécute les commandes

adéquates.

Avec des langages entièrement compilés comme C++, C ou Pascal, si l’on souhaite exécuter

un même programme sur dix plates-formes différentes, il faudra disposer d’un compilateur

pour chacune de ces plates-formes. Avec le langage Java, le code n’est compilé qu’une seule

fois, et peut s’exécuter sur n’importe quelle plate-forme à condition de retrouver sur la

machine du client de cette plate-forme une machine virtuelle Java (Java Virtual Machine).

Nous vous présentons dans la suite le principe de fonctionnement d’EGM.

4.1.2 Fonctionnement

Nous avons regroupé tous les fichiers nécessaires à l’exécution de cette application, en un

seul fichier archive (EGM.JAR) qui se trouve sur le serveur WEB. En effet, Java propose

l'utilitaire JAR dans le JDK, un utilitaire permettant de rassembler les différents packages

(fichiers .class) d'une application au sein d'une archive compressée, afin d'en assurer

l'intégrité et la taille. Ce fichier peut être exécuté par la suite grâce à la machine virtuelle Java

qui se trouve sur le Serveur WEB. La figure 5.5 résume le principe de fonctionnement

d’EGM.


Figure 5.5 - Schéma de fonctionnement d’EGM

4.1.3 Fonctionnalités

Nous vous présentons ci-dessous les principales fonctionnalités d’EGM :

• Construire les modèles EXPRESS-G : A l’aide de l’interface graphique comme le

montre la figure 5.6, l’utilisateur crée de manière assistée ses modèles EXPRESS-G

incluant les entités, les types, les attributs, les relations d’associations et les relations

d’héritage (simple/multiple). Les informations concernant ces objets sont saisies grâce

à des boites de dialogue comme illustré dans la figure 5.7. Une fois placés, ces objets

doivent être reliés entre eux. Pour cela il suffit de les sélectionner et choisir le type de

la relation (association ou héritage) et enfin les relier à l’aide de la souris. Une fois le

modèle EXPRESS-G construit, on peut l’enregistrer au format orignal, puis le rouvrir

pour une utilisation ou une modification. Un modèle EXPRESS-G peut être imprimé

au format PostScript.

SERVEUR WEB

EGM.JAR (Fichier exécutable

sur toutes les plates-formes)

Téléchargement &

Exécution

Machine Virtuelle JAVAM hi

Poste Client A Poste Client B


Figure 5.6 - L’interface Graphique EGM

Figure 5.7 - Insertion d’objets EXPRESS-G


• Conversion des modèles EXPRESS-G en EXPRESS : La caractéristique

fondamentale de cet outil est la conversion d’un modèle EXPRESS-G en EXPRESS,

dans ce cas on fait appel à un analyseur syntaxique et sémantique dont le rôle est celui

d’un compilateur et qui permet de vérifier que la conversion d’EXPRESS-G en

EXPRESS soit toujours conforme au langage EXPRESS. En cas d’erreur graphique

dans un modèle EXPRESS-G, l’outil le signale à l’aide d’un message (Erreur de

compilation). Si la conversion s’est bien déroulée, vous pouvez utiliser un éditeur

EXPRESS intégré dans le même outil qui permet d’ouvrir les fichier EXPRESS

générés et éventuellement faire des modifications (Figure 5.8).

Figure 5.8 - L’Editeur EXPRESS

4.2 Interface d’Accès aux Données de Produit

l’Interface d’accès aux Données de Produit (IADP) est une application WEB qui permettra

aux acteurs d’une Entreprise Virtuelle de gérer facilement à distance le stockage et le partage

de données dans l’Entrepôt de Données. Nous avons développé cette application à l’aide du

langage PHP.


4.2.1 Le langage PHP

PHP est un langage interprété (un langage de script) exécuté du côté serveur (comme les

scripts CGI, ASP, etc.) et non du côté client (un script écrit en Javascript ou une applet Java

s'exécute sur votre ordinateur). La syntaxe du langage provient de celles du langage C, du Perl

et de Java [RAW00].

Créé initialement par Rasmus Lerdorf pour un projet personnel, appelé PHP/FI, le langage a

eu un rapide succès au sein de la communauté Web, ce qui lui a valu d'être complètement

réécrit par six nouveaux développeurs pour s'appeler PHP3. A la fin de l'année 1999, une

version bêta de PHP, baptisée PHP4 est apparue.

Ses principaux atouts sont:

• Multi-plateforme, PHP fonctionne aussi bien sur UNIX, LINUX, que WINDOWS,

• Portable, un script PHP pourra être porté sans aucune modification vers n’importe

quelle plate-forme,

• Simplicité d'écriture de scripts,

• Possibilité d'inclure le script PHP au sein d'une page HTML (contrairement aux scripts

CGi, pour lesquels il faut écrire des lignes de code pour afficher chaque ligne en

langage HTML),

• Simplicité d'interfaçage avec des bases de données (de nombreux SGBD sont

supportés, mais le plus utilisé avec ce langage est MySQL),

• L'intégration au sein de nombreux serveurs Web (Apache, Microsoft IIS, etc.).

Mais le point fort de PHP par rapport à d’autres langages comme JAVA et Perl, reste dans sa

simplicité d’interfaçage avec un grand nombre de bases de données. La plus utilisée est

MySQL [RIG01][DUB00].

Un script PHP est un simple fichier texte contenant des instructions écrites à l'aide de

caractères incluses dans un code HTML à l'aide de balises spéciales et stocké sur le serveur.

Ce fichier doit avoir l'extension ".php" et non pas ".HTML" pour pouvoir être exécuté par le


serveur. Un exemple de script PHP est illustré dans la figure 5.9. On notera bien évidemment

que la fonction echo permet d'afficher sur le navigateur la chaîne délimitée par les guillemets.

Figure 5.9 - Exemple simple d’un script PHP

Afin de faire fonctionner PHP, on a mis au point un package appelé EasyPHP27 (l ‘équivalent

de JDK de Java). EasyPHP installe et configure automatiquement un environnement de travail

complet permettant de mettre en œuvre toute la puissance et la souplesse qu’offrent le langage

dynamique PHP et son support efficace des bases de données. Le package EasyPHP contient :

• Le serveur Web Apache,

• L’interpréteur de scripts PHP,

• La base de données MySQL.

4.2.2 Fonctionnement

Lorsqu’un utilisateur de l’Entreprise Virtuelle, lance à l’aide de IADP une requête au serveur

WEB, il se passe les choses suivantes (Figure 5.10):

1. Le navigateur envoie la requête au Serveur WEB,

2. Le Serveur transmet la requête à l’interpréteur de script PHP,

27Ce KIT est disponible sur http://www.easyphp.org

Hello_World.Php<html> <head><title>Exemple</title></head> <body> <?php echo "Hello world"; ?> </body> </html>


3. L’interpréteur de script interpéte le code php et communique éventuellement avec

l’Entrepôt de données (MySQL), puis, si le script est sans erreur, génère du code HTML

et le renvoie au Serveur WEB,

4. Enfin, le serveur WEB renvoie le code HTML au Navigateur qui affichera les résultats de

la requête.

Figure. 5.10 - Schéma de fonctionnement d’une requête de IADP

4.2.3 Fonctionnalités

Nous vous présentons dans cette section les principales fonctionnalités de IADP :

Accès protégés

IADP offre un accès sécurisé au données de l’entrepôt. Pour y accéder, chaque utilisateur de

l’Entreprise Virtuelle est invité à saisir son compte utilisateur et son mot de passe comme le

montre la figure 5.11.

Ces comptes utilisateurs sont créés par l’administrateur de l’Entreprise Virtuelle. En effet,

IADP possède deux interfaces, une pour l’utilisateur et l’autre pour l’administrateur.

Serveur WEB (APACHE)

Interpréteur de

Script PHP

Entrepôt de

Données (MySQL)

Client Navigateur

1

4

32


Figure 5.11 - Accès sécurisé à l’IADP

Upload

L’Upload est l’opération qui permet de stocker des fichiers dans l’Entrepôt de données. En

cliquant sur le bouton Upload (Figure 5.11), un formulaire apparaît dans le navigateur (Figure

5.12). Ce formulaire va permettre de, sélectionner le fichier à stocker dans l’entrepôt, de lui

donner un nom ainsi qu’une description, ajouter un mot clé pour l’indexation et spécifier les

droits d’accès à ce fichier. Enfin, l’utilisateur peut stocker le fichier sélectionné en cliquant

sur le bouton Upload. Le fichier sélectionné ne sera ajouté à l’entrepôt de données que si sa

taille ne dépasse pas celle autorisée par l’administrateur.


Figure 5.12 - Upload d’un fichier

Download

Il s’agit de télécharger un fichier de l’entrepôt de donnée vers le poste client. Là aussi, le

fichier ne sera téléchargé que si son propriétaire l’avait autorisé lors de son Upload (Droits

d’accès). Pour télécharger un fichier, il suffit de le sélectionner et cliquer sur l’icône

Download. Cette action forcera le navigateur à ouvrir une boîte de dialogue "Enregistrer sous"

comme illustré dans la figure 5.13.


Figure 5.13 - Download d’un fichier

Visualiser le contenu d’un fichier

IADP offre un support de travail avec des documents hétérogènes. En effet, une Entreprise

Virtuelle se compose de personnes dispersées géographiquement, utilisant dans le cadre de

leur travail des informations de tous les types incluant des textes, des images, des plans, des

catalogues, etc. A cet effet, IADP permet de visualiser en ligne le contenu des fichiers stockés

dans l’entrepôt sans avoir à les télécharger. Le tableau 5.2 représente les types de fichiers

supportés.

Type Fichier Description *.ExpG Fichier EXPRESS G *.EXP Fichier EXPRESS *.DOC Fichier Word *.PPT Fichier Power Point *.PDF Fichier PDF *.HTML Fichier HTML (*.GIF) et (*.JPG) Fichier Graphique

Tableau 5.2 - Types de fichiers supportés par IADP


La figure 5.14 représente l’exemple d’affichage en ligne d’un fichier de type GIF.

Figure 5.14 - Visualisation en ligne

Indexation

IPDA possède également un moteur de recherche, qui permet de retrouver facilement un

fichier stocké parmi des centaines d’autres. Pour cela, il suffit de taper un critère de recherche

et appuyer sur le bouton Rechercher.

Cette recherche est exécutée à l’aide d’un script PHP. Ce script est simple, il effectue dans un

premier temps une requête SQL sélectionnant les fichiers contenant les critères entrés par

l’utilisateur. Puis il affiche le nombre de fichiers retournés, et une boucle while exploite ces

fichiers et les affiche les uns à la suite des autres. Les résultats seront affichés en fonction du

mot clé saisi lors de la création du fichier (upload) d’origine dans l’entrepôt.

IPDA vous permet également de mettre à jour, déplacer, copier, renommer ou effacer les

fichiers et dossiers. Nous vous récapitulons toutes les fonctionnalités de IADP dans le

tableau 5.3:


Fonctionnalités Description

Accès sécurisé Accès par Login et mot de passe

Upload Stockage d’un fichier

Dowlonload Téléchargement d’un fichier

Visualisation Visualisation en ligne du contenu d’un fichier

Indexation Recherche facile de fichiers à l’aide d’un moteur de

recherche

Copier, déplacer, effacer, mise à jour Opérations sur les fichiers et les dossiers

Tableau 5.3 - Résumé des fonctionnalités de IADP

5. Scénario de démonstration

Afin de mieux comprendre l’infrastructure proposée, nous allons considérer le scénario

suivant. Un constructeur automobile désire réaliser un projet pour des clients potentiels

importants. Nous prenons le cas de la personnalisation des voitures (Customizing). Pour le

constructeur, c'est une manière de se rapprocher de ses clients en proposant des véhicules

individualisés. Il se démarque ainsi de la concurrence et fidélise la clientèle grâce à une

connaissance plus fine des goûts et des besoins de chacun. Pour cela, le constructeur

automobile (Donneur d’ordre) doit :

1. Trouver des partenaires potentiels et sélectionner parmi eux ceux qui peuvent lui offrir le

plus de chance pour que son offre soit acceptable,

2. Négocier avec les partenaires sélectionnés afin d’arriver à une offre commune,

3. Et enfin, réaliser le projet.

Nous vous décrivons ci-après ces trois phases.


5.1 Recherche de partenaires

Pour la recherche de partenaires, Le donneur d’ordre va publier toutes les informations

pertinentes pour son projet dans des dossiers accessibles à tous les partenaires potentiels. La

documentation d’un projet peut par exemple regrouper :

• Les dossiers d’appels d’offres,

• Les dossiers d’avancements,

• Les dossiers de conception,

• Les dossiers de fabrication.

La figure 5.15 illustre le cas des dossiers d’appels d’offres. Les entreprises intéressées par un

appel d’offres prennent contact avec l’administrateur de l’infrastructure pour pouvoir y

accéder, évitant ainsi que les concurrents puissent rechercher des informations confidentielles

sur ces projets.

Figure 5.15 - Accès au dossier d’Appel d’Offres par le partenaire

Les partenaires peuvent également accéder facilement à un appel d’offre en utilisant le

moteur de recherche et en tapant un critère de sélection (référence de l’appel d’offre). Le

moteur de recherche se charge d’afficher le résultat comme le montre la figure (5.16).


Figure 5.16 - Résultat de recherche d’un document d’appel d’offre

5.2 Soumission et négociation

Les entreprises intéressées à participer à des projets soumettent leurs candidatures à l’entrepôt

de données (Upload). Elles enregistrent les informations pertinentes concernant leurs

compétences et elles insèrent de plus un lien vers leur serveur Web propre. Celui-ci contient

des informations plus détaillées les concernant. Le Donneur d’ordre du projet, peut ainsi

garder l’initiative de la recherche et du choix des partenaires potentiels ayant les compétences

convenant le mieux à ses besoins. Lorsque le donneur d’ordre estime qu’il a reçu

suffisamment d’offres, il procède au choix des partenaires.

5.3 Réalisation du projet

Une fois que les partenaires ont décidé de travailler ensemble, il s’agit d’intégrer rapidement

les ressources existantes à partager afin de collaborer efficacement. Nous allons prendre le cas

de la personnalisation des portes. Le constructeur automobile a décidé de faire appel à un

bureau d’étude dont le rôle principal serait la conception (DESIGN) des portes selon les

besoins du consommateur. Le constructeur automobile a décidé également de faire appel à un

atelier de fabrication qui s’occupera de la fabrication finale des portes. La figure 5.17 illustre

l’Entreprise Virtuelle considérée.


Figure 5.17 - Illustration schématique de l’entreprise Virtuelle considérée

Dans un premier lieu, un responsable du bureau d’études, va devoir récupérer toutes les

informations dont il aura besoin pour son travail. Pour cela il va devoir ouvrir une session et

télécharger tous les documents concernant le projet (cahier de charges). Il pourrait

éventuellement utiliser l’outil d’aide à la modélisation EXPRESS-G Modeler, pour proposer

ses modèles STEP.

Une fois que le bureau d’étude aura terminé son travail, il va devoir rouvrir une session afin

de stocker dans l’entrepôt de données toutes les informations dont aurait besoin l’atelier de

fabrication. Enfin, l’atelier de fabrication à son rôle va ouvrir une session et télécharger toutes

les informations nécessaires afin de débuter la fabrication des portes. La figure 5.18 résume le

scénario présenté.

Constructeur Automobile(Donneur d’Ordre)

Atelier de Fabrication(Sous-Traitatnt)

Conception Fabrication des Portes

Bureau d’Etudes (Sous-Traitatnt)


Figure 5.18 - Scénario de fabrication de portes entre partenaires

6. Conclusion

Dans ce chapitre, nous avons proposé une infrastructure pour la modélisation, l’échange et le

partage de données de produit. Nous avons montré comment l’intégration des nouvelles

technologies issues de champs de la communication (Internet + Web) et de standardisation

(STEP) pouvait apporter un certain nombre d’éléments de réponse aux problèmes posés par


Bureau d’Etudes (Sous-Traitant)

Constructeur Automobile(Donneur d’Ordre)

Atelier de Fabrication(Sous-Traitatnt)

INTERNET

Responsable d’Etudes

Responsable Atelier

1. Ouverture d’une session par un responsable du Bureau d’Etudes & téléchargement de toute information nécessaire pour la conception

2. Ouverture d’une session par le responsable du Bureau d’Etudes & stockage de toutes les informations nécessaires à la fabrication.

3. Ouverture d’une session par le responsable de l’Atelier de Fabrication pour télécharger toutes les informations nécessaires à la fabrication.

Serveur WEB

Entrepôt de Données

1

2

3


L’originalité de cette infrastructure réside dans le fait qu’elle intègre une application d’aide à

la modélisation STEP et une application pour la gestion du stockage et partage de

l’information en une seule plate-forme. Chaque partenaire devra ainsi créer ses modèles en

EXPRESS-G et les convertir automatiquement en EXPRESS, il pourra ensuite utiliser une

interface pour stocker ces modèles ou pour stocker ou accéder à d’autres informations.

En résumé, l’infrastructure proposée va permettre de faire passer les acteurs du

développement de produit, d’une organisation ou les échanges d’informations sont répartis et

diffus, à une organisation ou ils sont structurés, distribués, centralisés et partagés.

Conclusion Générale 140

Conclusion Générale

BILAN

Cette thèse a présenté un cadre méthodologique pour la représentation des points de vue des

acteurs participants au développement du produit ainsi qu’une infrastructure informatique

pour la modélisation, l ‘échange et le partage des données de produit dans le contexte de


Les hypothèses et les critiques faites sur les modèles de la norme STEP au début du travail, et

sur lesquelles s’est basée la définition de la problématique traitée étaient :

• Les modèles de STEP ne prennent pas en compte la notion de point de vue.

• Le manque de modèles d’expression de besoin dans STEP suffisamment compréhensibles

pour assurer une communication efficace et non ambiguë entre les acteurs concernés.

• Les modèles de STEP sont statiques et ne fournissent qu’une représentation partielle du

produit, ils n’assurent que la structure et la géométrie et le lien avec la fabrication reste

absent.


Partant de ces hypothèses, les travaux présentés dans le cadre de ce mémoire ont eu pour

objectif de mettre en place un cadre méthodologique et applicatif pour enrichir les modèles de

STEP en abordant deux aspects :

• La mise en place d’une méthodologie pour construire des modèles à différents niveaux

d’abstractions permettant de prendre en compte les points de vue de l’ensemble des

acteurs,

• La mise en place d’une infrastructure informatique pour l’échange et le partage des

modèles et données de produit dans le contexte de l’Entreprise Virtuelle.

L’étude des travaux existants sur les techniques de modélisation et les approches pour la

conception et la fabrication intégrées susceptibles de servir de base pour la satisfaction de ces

objectifs nous ont permis de sélectionner les concepts et techniques clés sur lesquels se base

le cadre méthodologique proposé.

En terme de formalisme de modélisation, notre choix s’est focalisé sur le langage EXPRESS,

ce qui va permettre d’un côté de faciliter l’échange et le partage de l’information et d’un autre

côté l’intégration et la représentation des connaissances métiers tout au long du cycle de

développement du produit.

En terme de méthodologie pour la construction des modèles liés aux points de vue des

acteurs, nous nous sommes basés sur la méthode FBS. La méthode FBS s’appuie sur un

ensemble de modèles susceptibles de prendre en compte les connaissances métiers dès les

premières phases du Projet (Expression des besoins), et par un enrichissement progressif

(Fonction, Comportement, Structure) jusqu’à la définition complète du produit. Ces modèles

sont regroupés dans le Modèle de Produit. Nous nous sommes également appuyés sur un

Modèle de Processus pour décrire les processus de fabrication. Un couplage entre les deux

modèles de Produit et de Processus a été proposé afin d’assurer la cohérence entre la

conception et la fabrication.


On a mis également en place une infrastructure informatique support à l’Entreprise Virtuelle.

Cette infrastructure offre aux différents partenaires un environnement intégré pour la

modélisation, le stockage et le partage des données de produit. Elle est le résultat d’intégration

des techniques de communication (Internet et WEB) et des techniques de standardisation

(STEP).

PERSPECTIVES

Ce travail ouvre la voie à notre sens vers diverses perspectives de recherche qui se situent sur

deux plans : un plan méthodologique et un plan technologique.

Pour ce qui est du plan méthodologique, il serait intéressant de le compléter par la définition

d’un ensemble de règles de cohérence entre modèles. L’objectif est d’assurer un continuum de

transformations cohérentes des différents modèles à l’issue de la prise en compte des points

de vue des acteurs. Le cas le plus fréquent est celui du modèle de structure qui change au fur

et à mesure que le concepteur prenne en compte les points de vue du fabricant.

Pour ce qui est du plan technologique, des tentatives de plus en plus nombreuses sont en cours

afin de coupler les modèles de STEP avec des modèles plus puissants tels que XML. On peut

citer les recherches effectuées dans le cadre du projet (Partie 28 : Encodage en XML ) par

l’ISO, et qui proposent d'ores et déjà une démarche pour convertir les modèles STEP en

modèles XML. Mais cette migration de STEP vers XML se heurte encore à des difficultés. En

effet, les essais d'export de fichiers réalisés avec XML montrent qu'ils sont de 5 à 10 fois plus

gros que les fichiers équivalents STEP.

Bibliographie 143

Bibliographie

[AIT93] Advanced Information Technology for European Manufacturing Industry. Available from Internet :<http://www.ait.org.uk/index.htm>.

[AIT97] EP22148: Integration Platform for AIT. Available from Internet

<http://www.ait.org.uk/projects/aitip2/leaflet.htm>, 1997. [AND91] ANDREASEN, M. The theory of domains. Workshop on Understanding Function and Function

to Form Evolution, Cambridge University, UK, 1991. [BER96] BERNARD, A. et G. TAILLANDIER. Le prototypage rapide. Éditions Hermès, 1996, 256 p. [BOD00] BODINGTON, R. and LÄMMER, L. Integrating the Enterprise using the PDM schema and

the PDM Enablers. Product Data Technology Europe 2000 9 th Symposium, 2-5 May 2000, Noordwijk, The Netherlands.

[BOU94] BOURDICHON, P. L’ingénierie simultanée et la Gestion des systèmes industriels. Hermès,

collection Systèmes d’Informations, Paris, 1994. [BOU95a] BOUAZZA, M. La norme STEP, Hermès, Paris, 1995. [BOU95b] BOUAZZA, M. Le langage EXPRESS, Hermès, Paris, 1995. [CHA99] CHAMBOLLE, F. Un modèle produit piloté par les processus d'élaboration : application au

secteur automobile dans l'environnement STEP. Thèse de Doctorat de l'Ecole Centrale Paris, 1999.

[CHE96] CHESBOURGH, H.W. et TEECE, D.J. When is Virtual Virtuous ? Organizing for innovation.

Harvard Business Review, January-February 1996. [CLO00] CLOUX, P.Y. et DOUSSOT, D. et GERON, A. Architectures client-serveur, Internet et

intranets, des Cgi aux Ejb. Dunod, 2000. [COA92] COAD, P. and YOURDON, E. Object-Oriented Analysis. Prentice-Hall, Englewood Cliffs,

N.J., 1992.

http://www.ait.org.uk/index.htm

Bibliographie 144

[CRA95] CRABOWSKI, H. and LOSSACK, R.S. and WEIS, C. Supporting the design process by an integrated knowledge based design system. Advances in formal design methods for WAD, IFIP international Conference, Mexico 1995.

[DAV90] DAVENPORT, T.H and SHORT, J. The new Industrial Engineering : Information Technology

and Business Process redesign. Sloan Management Review, 1990, pp. 11-27. [DEL98] DELOITTE & TOUCHE. 1998 Vision in Manufacturing : A Global Manufacturing Survey.

Executive Summary, Deloitte & Touche Consulting, 7p. [DEN95] DENNING, P. & HIEB, M. & MENASCE, D. The workflow Module. Available from Internet

<http://cne.gmu.edu/modules/workflow/>, 1995. [DUB00] DUBOIS, P. MySQL. CampusPress, ISBN : 2744008826, 2000. [ELM95] EL MHAMEDI A., LERCH C., SONNTAG M.. Modélisation des activités et des processus

des systèmes de production : une approche multidisciplianire. Congrès International de génie Industriel, Montréal, Canada, 18-20 octobre 1995.

[ELM97] EL MHAMEDI A., LERCH C., MARIER S., SONNTAG M., VERNADAT, F. Intégration des

activités non structurées dans la modélisation des systèmes de production ACNOS. Rapport final du projet ACNOS – action incitative du DSPT 8 en productique du MENESR. 1997.

[FER98] FERU, F. et VIEL, C. Echanger avec le protocole d'application 203 de STEP : Echange et

partage de données CAO et GDT. Ass. GOSET, Nanterre, ISBN: 2-9513382-0-1, 1998. [FLA01] FLANAGAN, D. et GACHET, A. Java In A Nutshell, manuel de référence pour Java 2, JDK

1.2 et 1.3. O'Reilly (In a Nutshell),ISBN: 2841770656 2001. [GAM98] TOLENAERE, M. Modélisation par Entités. Conception de Produit mécaniques : méthodes,

modèles et outils, Hermes, 1998. [GEO95] GEORGAKOPOULOS, D. and HORNICK, M, SHETH, A. An Overview of Workflow

Management : From Process Modeling to Workflow Automation Infrastructure. Distributed and Parallel Databases, An International Journal, 3, 1995.

[GHE00] GHERMOUTI, S. Sécurité Internet : Stratégies et technologies. Dunod, ISBN: 2100053957,

2000. [GHO01] GHODOUS, P. and MARTINEZ, M and VANDORPE, P. Collaborative and Standard Design

and Manufacturing Model. International Journal of Computer Applications in Technology (IJCAT)2001.

[GOG99] GOGLIN, J.F. et USCLADE, P. Du client-serveur au web-serveur. Hermès science

publications, ISBN : 2746200279, 1999. [GZA00] GZARA, L. Les Patterns pour l'Ingénierie des Systèmes d'Information Produit. Thèse INPG de

Grenoble, soutenue le 12 décembre 2000. [HAA01] HAAN, J. and YAMAMOTO, M. and LOVINK, G. Production planning in Japan:

rediscovering lost experiences or new insights?. International Journal of Production Economics, Volume 71, Issues 1-3, 6 May 2001, Pages 101-109.

[HAM93] HAMMER, M. & CHAMPY, J. Reengineering the corporation : a manifesto for business

revolution. Harper Collins Publishers, Inc. Ed., New-York . Traducion française : « le reenigineering », Paris, Dunod, 1993.

[HAR96] HARDWICK, M. and SPONNER, D.L. and RANDO, T. and MORRIS, K.C. Sharing

Manufacturing Information in Virtual Enterprises. Communications of the ACM, Vol.39, No. 2 pp. 46-54, 1996.

Bibliographie 145

[HAR97] HARANI, Y. Une approche Multi-Modèles pour la capitalisation des connaissances dans le

domaine de la conception. Thèse de doctorat de l'Institut National Polytechnique de Grenoble, 1997.

[HSI02] HSIAO, S.W. Concurrent design method for developing a new product. International Journal

of Industrial Ergonomics, Volume 29, Issue 1, January 2002, Pages 41-55. [HUA97] HUAU, P. La conception automobile dans STEP. Goset actualités n°14 septembre octobre

1997. [IGE80] IGES, Initial Graphics Exchange Specification : ANSI Y 14.26M, ANSI – American National

Standard Institute, USA, 1980. [ISO00a] ISO 10303-23 :2000. Industrial automation systems and integration -- Product data

representation and exchange -- Part 23: Implementation methods: C++ language binding to the standard data access interface.

[ISO00b] ISO/TS 10303-27 :2000. Industrial automation systems and integration -- Product data

representation and exchange -- Part 27: Implementation methods: Java TM programming language binding to the standard data access interface with Internet/Intranet extensions.

[ISO01] ISO 10303-24 :2001. Industrial automation systems and integration -- Product data

representation and exchange -- Part 24: Implementation methods: C language binding of standard data access interface.

[ISO94a] ISO 10303-11 - Industrial automation systems and integration — Product data representation

and exchange – Part 11: Description Methods: The EXPRESS language reference manual, 1994.

[ISO94b] ISO 10303-21 - Industrial automation systems and integration — Product data representation

and exchange – Part 21: Implementation methods: Clear Text Encoding of the Exchange Structure (Physical File), 1994.

[ISO94c] ISO 10303-41 - Industrial automation systems and integration — Product data representation

and exchange – Part 41: Integrated Generic Resources: Fundamentals of Product Description and Support, 1994.

[ISO94d] ISO 10303-42 - Industrial automation systems and integration — Product data representation

and exchange – Part 42 Integrated Generic Resources: Geometric and Topological Representation, 1994.

[ISO94e] ISO 10303-43 - Industrial automation systems and integration — Product data representation

and exchange – Part 43: Integrated Generic Resources: Representation Structures, 1994. [ISO97] ISO 10303-22, Industrial automation systems and integration — Product data representation

and exchange – Part 22: Implementation methods: Standard Data Access Interface, 1997. [ISO01] ISO/AWI 10303-109, Industrial automation systems and integration, Product data

representation and exchange -- Part 109: STEP assembly model for products, Stage Date : 2001-01-24.

[ISO02] ISO 10303-21 : 2002. Industrial automation systems and integration -- Product data

representation and exchange -- Part 21: Implementation methods: Clear text encoding of the exchange structure.

[ISO98] ISO 10303-32 :1998. Industrial automation systems and integration -- Product data

representation and exchange -- Part 32: Conformance testing methodology and framework: Requirements on testing laboratories and clients.

Bibliographie 146

[JAG93] JAGOU, P. Concurrent Engineering : La maîtrise des coûts, des délais et de la qualité. Hermès, Paris, 1993.

[KAE00] KAEO, M. Sécurité des réseaux. CampusPress, ISBN : 2744008508, 2000. [KER99] KERR, M. and ROLLO, T. and BODINGTON, R. Experience in the use of STEP for data

exchange between PDM systems, Product data Technology Europe 1999, 8 th Symposium, 13-16 April 1999, Stavanger, Norway.

[KHAa00] EL KHALKHALI, I. and MARTINEZ, M. and FAVREL, J. Integrated Product Development

: Information Technology Integration. In proceeding of the International Conference of Systems Engineering and Information & Communication Technology. Nîmes, France - September, 11-13, 2000, p194-200.

[KHAb00] EL KHALKHALI, I. & GHODOUS, P. & MARTINEZ, M. & FAVREL, J. Atelier de Génie

logiciel pour la modélisation intégrée Produit-Processus. Actes du 4ème congres International de Génie Industrielle, Vol 1, 119-128, Marseille- 11-15 juin, 2000.

[KHAc01] EL KHALKHALI, I. & GHODOUS, P. & MARTINEZ, M. & FAVREL, J. An Information Infrastructure for the Virtual Manufacturing Enterprise. In CD proceedings of EDA 2001, Las Vegas- August 5-8, 2001.

[KHAd02] EL KHALKHALI, I. & GHODOUS, P. & MARTINEZ, M. & FAVREL, J. An information

infrastructure to share product models using STEP standard. In CD proceedings of the 9th ISPE International Conference on Concurrent Engineering: research and applications, Cranfield University, United Kingdom, 27th - 31st JULY, 2002.

[KOU01] KOUFTEROS, X. and VONDEREMBSE, M. and DOLL, W. Concurrent engineering and its

consequences. Journal of Operations Management, Volume 19, Issue 1, January 2001, Pages 97-115.

[LAM00] LÄMMER, L. and Machner, B. Standards as enabler for PDM in virtual enterprise., Product

Data Technology Europe 2000 9 th Symposium, 2-5 May 2000, Noordwijk, The Netherlands. [LEF98] LEFEBVRE, A. Web client-serveur. Eyrolles, ISBN: 2212090390, 1998. [LEQ99] LEQUEUX, J.L. Manager avec les ERP «Progiciels de Gestion Intégrés»

et Internet. Editions d’organisation, 1999. [LOR97] LORINO P. Méthodes et pratiques de la performance – le guide du pilotage, Les Editions

d’organisation. Paris, 1997. [LUI96] LUIK, J. .L’entreprise virtuelle. Conférencier invité (Forum organisé par le ministère du

développement économique, du commerce et du tourisme en Ontario, adresse Internet : www.2ontario.com/archives/chfall96.

[MAI90] MAILLAT, D. et CREVOISIER, O. et LECOQ, B. Réseaux d'innovation et dynamique

territoriale: l'arc jurassien. Dossiers Université de Neuchâtel, IRER, Nov. 1990.

[MAS89] MASAAKI, I. Kaizen : The Key to Japan's Competitive Success. McGraw-Hill, 1989. [MAU95] MAURINO, M. La gestion des Données Techniques. Masson, Paris, 1995. [MEN93] MENTZAS, G.N. Coordination of Joint Tasks in Organisational Processes. Journal of

Information Technology, Vol 8, 1993, pp 139-150. [MEY88] MEYER, B. Object-Oriented Software Construction, Prentice Hall, Hemel Hempstead,

UK,1988.

http://www.2ontario.com/archives/chfall96

Bibliographie 147

[MOH97] Morhmann, J. AP214 Core Data for Mechanical Design Processes in the Manufacturing Industry, STEP FORUM 97, ProStep, 1997.

[MOK99] MOKA user guide, deliverable du consortitum MOKA htttp://www..kbe.coventry.ac.uk/moka/.

[MON92] MONY, C. Un modèle d'intégration des fonctions conception-fabrication dans l'ingénierie du produit. Thèse de l'Ecole Centrale de Paris, France, 1992.

[MOR96] MORTENSEN N.M. & ANDREASEN, M..M. Designing in an interplay with a product

model, Explained by design units. TMCE'96, Budapest, Hungary, 1996. [MOR00] MORRIS, K.C. Improving PDM Testability through Standards Harmonization. Product Data

Technology Europe 2000 9 th Symposium, 2-5 May 2000, Noordwijk, The Netherlands. [NGM97] AGILITY FORUM, Leaders for Manufacturing et Technologies Enabling Agile

Manufacturing. Next-Generation Manufacturing Project : A Framework for Action. Rapport d’un groupe de travail sur le secteur manufacturier américain, 1997.

[OMG98] OMG Manufacturing Domain Task Force : PDM Enablers revised Submission. Available from

Internet <http://www.omg.org/homepages/mfg/mfgppepdm.htm>, 1998. [OPA96] EP 20377: Integrated Information and Process Management. Available from Internet

<http://www.ait.org.uk/projects/projects.htm#OPAL>. [PDM99] PDM schema version 1.1 de la spécification pré-normative de PDM Schema. Available from

Internet <http://www.pdm-if.org/pdm_schema> [PER98] PERLO, A. et C, HILLS. Réunir et souder une équipe virtuelle. L’Expansion Management

Review, pp. 114-119, 1998. [PRO96] PROBST, A.R. Vers des systèmes d’information génériques pour les entreprises virtuelles.

2ième colloque international de management des réseaux d’entreprise, École des HEC, Université de Lausanne, Available from Internet <http//inforge.unil.ch/cimre96>.

[RAN95] RANDOING, M. Les SGDT. Hermès, Paris,1995. [RAW00] RAWAT, H. PHP Professionnel. Eyrolles (Solutions Développeurs), ISBN: 2212092350,

2000. [RBP91] RUMBAUGH, J. and BLAHA, M. and PREMERLANI, W. and EDDY, F. and LORENSEN,

W. Object Oriented Modelling and Design, Prentice-Hall International Editions, ISBN 0-13-630054-5, 1991.

[RIG01] RIGAUX, P. PRATIQUE DE MySQL ET PHP. O'Reilly, 2001. [RIS98] RiseStep EP 20459 : Enterprise Wide Standard Access to SEP Distributed Databases. Final

Demonstration (mars 1998). [ROS94] ROSENMAN, M.A. & GERO, J..S. The what, the how and the why in design. Appl. Art,

Intell. Vol. 8, No. 2, pp. 199-218, 1994. [ROS96] ROSENMAN, M. and GERO, J.S. Modelling multiple views of design objects in a

collaborative CAD environment. CAD, Vol 28, No 3, pp. 193- 205, Elsevier science Ltd, 1996.

[SAR99] SARDET, E. Intégration des approches modélisation conceptuelle et structuration

documentaire pour la saisie, la représentation, l'échange et l'exploitation d'informations : Application aux catalogues de composants industriels. Thèse de Doctorat en Informatique de l'Université de Poitiers, Poitiers, 1999.

http://www.omg.org/homepages/mfg/mfgppepdm.htm

http://www.ait.org.uk/projects/projects.htm#OPAL

http://www.pdm-if.org/pdm_schema

Bibliographie 148

[SCH94] SCHENCK, D. and WILSON, P. Information Modelling The EXPRESS Way, Oxford University Press, 1994.

[SHE96] SHELTON, R.E. Business Objects – Workflow. Data Management Review, Mars 1996. [SHI98] SHIMOMURA, Y. and TAKEDA, H., YOSHIOKA, M. and UMEDA, Y. and TOMIYAMA,

T. Representation of design object based on the functional evolution process model. Design Engineering Technical Conferences, ASME'98, Journal of Mechanical Design, Vol. 120, No. 2, (June 1998), pp. 221-229.

[STA02] STARBEK, M. and GRUM, J. Concurrent engineering in small companies. International

Journal of Machine Tools and Manufacture, Volume 42, Issue 3, February 2002, Pages 417-426 .

[TAS00] TASSO, A. Le livre de Java Premier Langage. Eyrolles, ISBN : 2212091567, 2000. [TOM99] TOMAS, J.L. ERP et progiciels intégrés : La mutation des systèmes d’information. Dunod :

Paris,1999. [TOY98] TOYOTA MOTOR CORPORATION. The Toyota production system. International public

affairs division planning group, 1998, document de l’entreprise, 44 p. [UME90] UMEDA, Y. and TAKEDA, H. and TOMIYAMA, T. and YOSHIOKA, M. Function,

behavior and structure. In Gero, J.S., editor, Applications of Artificial Intelligence in Engineering V, volume 1, pages 177-194, Berlin, 1990. Springer-Verlag.

[UME96] UMEDA, Y and ISHII, M and YOSHIOKA, M and TOMIYAMA, T. Supporting conceptual

design based on the Function-Behavior-State modeler. In Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AIEDAM) , Vol. 10, No. 4, pp. 275--288, September 1996.

[VDA86] VDA-FS, Vereinung Deutsche Autombilindustie Flächen Schnittstelle : DIN 66301, DIN-

Deutsches Instiut für Normung, Germany, 1986. [VER99] VERNADAT, F. Techniques de Modélisation en Entreprise : Application aux Processus

Opérationnels, Ed. Economica, 1999. [WFM99] Workflow Management Coalition. "Terminologie et Glossaire Workflow". v. 2.0 Fev. 1999.

Available from Internet < http://www.wfmc.org.>. [WIK00] WIKES, W. and BRÖKING, J. MERCI : Integration of EXPRESS based and XML based

component information representation, Product Data Technology Europe 2000 9 th Symposium, 2-5 May 2000, Noordwijk, The Netherlands.

[WOM96] WOMACK, J. et JONES, D. Penser l’entreprise au plus juste. Paris, Éd. Village Mondial,

1996, 404 p. [WOM90] WOMACK, J.P. et JONES, D.T. et ROOS, D. The Machine That Change the World.

Cambridge: MIT Press, 1990. [ZAR98a] ZARLI, A. and AMAR, V. and DIARD, F. and MARACHE, M. Combler le fosse entre STEP,

CORBA et la réalité Virtuelle pour les applications de nouvelle génération dans l'industrie du BTP, Actes du MICAD 98, Conférence C3-SGDT : Réussir l'intégration dans l'entreprise, paris, 17-20 mars 1998, France.

[ZAR98b] P. ZARIFIAN. L'émergence de l'organisation par processus : à la recherche d'une difficile

cohérence. Dans "Cohérence, Pertinence et Evaluation", groupe ECOSIP. ECONOMICA. 1996. Pp. 65 - 86.

http://www.wfmc.org/

Bibliographie 149

Résumé Dans le contexte d’Ingénierie Simultanée et d’Entreprise Virtuelle, un grand nombre d’informations sont utilisées et manipulées. L’exploitation de ces données pose des problèmes de communication tels que l’accès, l’échange et le partage d’informations entre des sites distants et entre des systèmes hétérogènes bien souvent incompatibles. C’est dans ce contexte que le projet STEP a été introduit. L’objectif de STEP est de définir une représentation non ambiguë des données de produit, interprétable par tout système informatique, et couvrant un très vaste domaine de connaissances. Cependant les acteurs travaillant simultanément au développement d’un produit sont nombreux et de spécialités très différentes : Concepteurs, Fabricants, Clients, Marketing, etc. Les points de vue qu’ils portent sur le même produit sont également très différents. Malheureusement les modèles STEP ne permettent pas de prendre en compte cette notion de point de vue. Ainsi, Le travail présenté dans cette thèse a pour objectif de mettre en place un cadre méthodologique pour la représentation et l’intégration des points de vue des acteurs de la conception et de la fabrication à différents niveaux d’abstraction. Une infrastructure informatique pour la modélisation, l’échange et le partage des données de produit est également proposée. MOTS-CLES : Ingénierie Simultanée, Entreprise Virtuelle, Standard STEP, Modélisation Produit-Processus, Infrastructure Informatique, Technologies WEB.

Abstract In Virtual Enterprise and Concurrent Engineering environments, a wide variety of information is used. A crucial issue is the data communication and exchange between heterogeneous systems and distant sites. To solve this problem, the STEP project was introduced. The STandard for the Exchange of Product model data STEP is an evolving international standard for the representation and exchange of product data. The objective of STEP is to provide the unambiguous computer-interpretable representation of product data in all phases of the product’s lifecycle. In a collaborative product development different types of experts in different disciplines are concerned by the product (Design, Manufacturing, Marketing, Customers,...). Each of these experts has his own viewpoint about the same product. STEP Models are unable to represent the expert’s viewpoints. The objective of our research work is to propose a methodology for representation and integration of different expert’s viewpoints in design and manufacturing phases. An Information Infrastructure for modelling, exchanging and sharing product data models is also proposed. KEYWORDS: Concurrent Engineering, Virtual Enterprise, STEP Standard, Product-Process modelling, Information Infrastructure, WEB Technologies.

Documents

Système intégré pour la modélisation, l'échange et le