système intégré pour la modélisation, l'échange et le
TRANSCRIPT
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.
Introduction Générale 2
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
Introduction Générale 3
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.
Introduction Générale 4
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.
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 6
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.
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 7
• 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.
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 8
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.
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 9
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.
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 10
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.
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 11
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
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 12
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.
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 13
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.
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 14
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é.
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 15
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 :
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 16
• 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
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 17
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.
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 18
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
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 19
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
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 20
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,
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 21
• 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
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 22
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.
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 23
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].
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 24
• 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
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 25
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.
Chapitre 1. L’Entreprise Manufacturière : Environnement et Nouvelles Formes d’Organisation 26
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
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 28
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.
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 29
• 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.
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 30
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.
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 31
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.
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 32
(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
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 33
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.
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 34
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;
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 35
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
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 36
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
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 37
(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
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 38
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.
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 39
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;
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 40
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.
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 41
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.
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 42
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.
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 43
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
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 44
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.
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 45
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.
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 46
- 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] :
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 47
- 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.
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 48
- 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.
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 49
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.
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 50
• 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é ?
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 51
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.
Chapitre 2. Modélisation, échange et partage de données de produit : La technologie STEP 52
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é.
Chapitre 3. Précision et approche de la problématique 54
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
Chapitre 3. Précision et approche de la problématique 55
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é.
Chapitre 3. Précision et approche de la problématique 56
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]
Chapitre 3. Précision et approche de la problématique 57
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.
Chapitre 3. Précision et approche de la problématique 58
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 :
Chapitre 3. Précision et approche de la problématique 59
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.
Chapitre 3. Précision et approche de la problématique 60
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
Chapitre 3. Précision et approche de la problématique 61
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.
Chapitre 3. Précision et approche de la problématique 62
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.
Chapitre 3. Précision et approche de la problématique 63
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
Expert Point de vue n°2
Expert Point de vue n°1
Interprétation Interprétation
Interprétation
…
Produit
REGLES DE COHERENCES
Expert Point de vue n°1
Expert Point de vue n°2
Expert Point de vue n°n
…
MODELE 1 MODELE 2 MODELE n
Chapitre 3. Précision et approche de la problématique 64
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.
Chapitre 3. Précision et approche de la problématique 65
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.
Chapitre 3. Précision et approche de la problématique 66
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 68
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.
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 69
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 70
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 …
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 71
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 72
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).
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 73
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 74
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 75
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.
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 76
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 77
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 78
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 79
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 80
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.
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 81
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 82
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
….
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 83
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 84
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 85
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 86
(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.
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 87
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 88
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 :
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 89
• 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.
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 90
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.
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 91
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.
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 92
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 93
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 94
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 95
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 96
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 97
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
Protection électrique
Fonction Electrique
Protection électro-
magnétique
Isolation électrique
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 98
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
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 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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 99
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 100
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
Protection électrique
Fonction Electrique
Protection électro-
magnétique
Isolation électrique
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
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 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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 101
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.
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 102
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
Assembler(Coquille Ecrou+Serre-Câble+Bloc
Contact M+Ecrou)+Plaquette
Assembler(Coquille Ecrou+Serre-Câble+Bloc
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
Chapitre 4. Méthodologie pour la modélisation intégrée Produit-Processus 103
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
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 105
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
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 106
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.
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 107
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.
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 108
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
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 109
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.
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 110
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 :
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 111
• 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,
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 112
• 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.
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 113
• 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
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 114
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 :
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 115
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.
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 116
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.
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 117
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
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 118
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
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 119
(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.
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 120
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
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 121
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.
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 122
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.
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 123
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.
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 124
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
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 125
Figure 5.6 - L’interface Graphique EGM
Figure 5.7 - Insertion d’objets EXPRESS-G
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 126
• 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.
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 127
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
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 128
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>
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 129
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
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 130
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.
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 131
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.
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 132
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
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 133
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:
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 134
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.
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 135
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).
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 136
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.
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 137
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)
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 138
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
l’Entreprise Virtuelle.
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
Chapitre 5 . Infrastructure pour la modélisation, l’échange et le partage des données de produit 139
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
l’Entreprise Virtuelle.
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.
Conclusion Générale 141
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.
Conclusion Générale 142
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.
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.
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.
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.
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.