Intégration des Fournisseurs dans la gestion des

exigences
MOURAD MESSAADIA, THIERRY GIDEL, FAROUK BELKADI, NADÈGE TROUSSIER, BENOÎT EYNARD.

UNIVERSITE DE TECHNOLOGIE DE COMPIEGNE,

CNRS UMR6253 Roberval BP 60319, Rue du docteur Schweitzer, 60203 Compiègne Cedex
{ mourad.messaadia, thierry.gidel, farouk.belkadi, nadege.troussier, benoit.eynard }@utc.fr

Résumé – La filière aéronautique est en phase de mutation, telle que celle de l’automobile il y’a vingt ans. Cette mutation
modifie la relation du donneur d’ordre (DO) avec ses fournisseurs. L’intégration verticale des fournisseurs au plus tôt
dans le cycle de vie du produit est un des axes d’évolution du point de vue du DO. Cette intégration verticale des
fournisseurs, doit permettre d’augmenter leur valeur ajoutée par la proposition d’innovations de produits et de process.
Du point de vue du fournisseur, cette intégration implique de maitriser de nouvelles compétences, une nouvelle
organisation et de nouveaux outils.
Nous faisons l’hypothèse que la participation des fournisseurs à la gestion des exigences, en particulier leur définition,
peut favoriser les innovations. Dans cet article nous nous intéressons à l’intégration de fournisseurs d’outils d’assemblage
dans le domaine aéronautique, et cela dès la phase de définition des exigences de l’utilisateur. Nous y proposons une
description des processus de gestion des exigences qui doit faciliter la compréhension des enjeux stratégiques et faciliter le
passage à l’action. Compte tenu de la complexité des systèmes aéronautiques, le travail reposera sur l’ingénierie système à
travers la norme EIA 632 et l’ingénierie des exigences (IE).
Abstract - Aeronautics is currently changing, such as automotive twenty years ago. This, changes the OEM and suppliers
relationship. One of the main OEM developments perspectives is the supplier vertical integration earlier in the product
life cycle. This supplier’s vertical integration should allow their added value through their products and process
innovations proposition. For the supplier, this integration involves the mastery of new skills this integration is the new
skills mastering, a new organization and new tools.
We make the hypothesis that the supplier’s participation in the requirement management, especially their definition,
facilitates the innovation. The purpose of this paper is the tool’s assembly supplier integration in the aeronautics field, and
this from the requirement user definition. We offer a description of the requirement’s management process, and this to
facilitate the understanding of strategic issues and facilitate the transition to action. Given the complexity of aeronautical
systems, this work is based on system engineering, through EIA 632 standard and requirements engineering (RE).

Mots clés – IE, DO, Fournisseur, EIA632, PLM.

Keywords - RE, OEM, Supplier, EIA632, PLM.

1 INTRODUCTION et ses fournisseurs [Le Dain, 2007] à travers l’élaboration de

Parmi les grands changements dans le développement de différentes formes de coopération avec différents degrés
produits, figure la durée de vie et les délais de mise sur le d’intégration. Ceci, dans le but de faire progresser les
marché des nouveaux produits. L'objectif de réduction du fournisseurs vers des niveaux d’autonomie plus élevés et les
cycle de développement n'est pas toujours atteint. Les derniers faire gagner en rang.
retards annoncés par Airbus sur le programme du gros porteur Cette progression dans la relation à été favorisée par
A380 en 2006 le montrent. l’expansion du concept du travail collaboratif et du concept
Parmi les raisons de ces échecs, nous constatons le manque de PLM (gestion du produit tout au long de son cycle de vie) qui
coordination dans la relation entre le DO (donneur d’ordre) et prend de plus en plus d’ampleur dans les stratégies élaborées
ses fournisseurs. Cette relation est caractérisée par la par les entreprises [CIMData].
participation du fournisseur dans le cycle de vie du produit Aussi, l’évolution des outils informatiques ainsi que des outils
jusqu’à son intégration dans ce cycle. Cette intégration des de transfert et d’échange de données dits PLM ont permis cette
fournisseurs dans la chaine de valeur du produit n’est pas une évolution de la collaboration entre DO et fournisseurs.
problématique nouvelle, beaucoup de travaux ont abordé cet Dans ce monde où la technologie informatique a pris une place
aspect et visent à trouver le meilleur moyen de réaliser cette majeure, le travail classique a connu une grande évolution.
intégration. Dans cette problématique nous trouvons les Cela a été constaté dans le secteur automobile [Tang et Qian,
travaux qui traitent l’aspect de l’interopérabilité [Berio et al., 2008]. Cette évolution s’est caractérisée durant les années
2004], échange de données [Xiao-li, 2002] et les normes quatre-vingt-dix par le déploiement des réseaux d’entreprises
établies tout au long du cycle de vie de produit [Patil et Sriram, fournisseurs des donneurs d’ordres automobiles. Ces réseaux
2005], et ceux qui traitent l’aspect organisationnel entre le DO se caractérisent par une « coopération verticale ». Cette
coopération se traduit par l’intégration des fournisseurs Coopération Verticale
équipementiers dans un processus de développement simultané
Coopération Diagonale
des voitures, dans la phase de planification/conception et dans Client (DO) PME
les phases d’études et de réalisation. PME PME
“Co”-conception Stratégique Niv 5
Les constructeurs aéronautiques étaient des entreprises très Co-conception “critique” Niv 4 PME PME
fortement intégrées, réalisant en interne la plupart des Développement délégué Niv 3 PME PME Filière
opérations pour la fabrication des avions. C’est dans les années Développement coordonné Niv 2
2000, que les constructeurs aéronautiques ont commencé à
Sous-traitance classique Niv 1
déléguer une partie de leur production, et à développer avec (Industrialisation)
Sous-traitance classique Niv 0
leurs fournisseurs des liens complexes, des relations de (Fabrication)
PME
partenariat à plus ou moins long terme. Fournisseur
Du fait de la complexité des systèmes aéronautiques, PME
l’ingénierie des exigences est fortement présente. Elle permet
la définition des spécifications, sachant qu’une spécification Coopération Horizontale
peut contenir un nombre très varié d’exigences (de 50 jusqu’à
quelques milliers) [Hellouin, 2002]. Les spécifications sont Figure 1. Typologie des coopérations
nécessaires pour rendre les exigences plus cohérentes,
maîtrisables et gérables au cours du développement du Les coopérations diagonales : Il s’agit de coopérations entre
système. Notre recherche se positionne à l’interface entre les entreprises qui n’entretiennent pas de transactions directes ni
DO et fournisseur, au moment où les exigences sont transmises de relations concurrentielles et dont les produits se complètent.
de l’un à l’autre. Les coopérations verticales : Il s’agit de coopérations entre
Après cette introduction, le deuxième paragraphe présente la entreprises ayant ou pouvant avoir une relation de
problématique. Le troisième aborde le cycle de vie du produit. client/fournisseur. L’un des acteurs à l’origine du projet
Le quatrième paragraphe traite d’une typologie des relations implique très fortement l’autre.
entre DO et fournisseur. Dans le cinquième, nous présentons
l’IE (l’ingénierie des exigences). Le sixième paragraphe 2.1 Coopération verticale
aborde la conception du système dans la nouvelle organisation Les années quatre-vingt-dix ont vu se déployer des réseaux
DO/fournisseur/client final (utilisateur). Enfin nous terminons d’entreprises fournisseurs des donneurs d’ordres automobiles.
par une synthèse et une conclusion. Ces réseaux se caractérisent par une « coopération verticale ».
1.1 Problématique La coopération verticale débute souvent par une relation dans
laquelle une entreprise (DO : Client) demande à son
Cette recherche est réalisée dans le cadre d’un projet régional. fournisseur (Sous-traitant) de réaliser une production selon un
Il étudie la relation entre le DO et ses fournisseurs. Ces cahier des charges précis. Le DO conserve la propriété
fournisseurs du secteur aéronautique, offrent des outils industrielle de son produit, la responsabilité et la marque du
d’assemblage. La question à laquelle nous tentons de répondre produit. Nous verrons que ce type de coopération peut évoluer
est : comment le fournisseur peut-il en participant au jusqu’au niveau de Co-développement entre fournisseurs et
développement du produit et du processus de fabrication, DO.
favoriser l’innovation ? L’objectif est que ces fournisseurs Dans l’industrie automobile, le partenariat vertical se traduit
aient une plus grande valeur ajoutée afin de rester compétitifs par l’intégration des fournisseurs équipementiers dans un
par rapport à leurs concurrents. L’hypothèse est que leur processus de développement simultané des voitures, dans la
intégration le plus amont du cycle de vie du produit, au niveau phase de planification/ conception et dans les phases d’études
des exigences favorisera l’innovation. et de réalisation.
Aussi dans le contexte de l’aéronautique, trois types de
2 RELATION ENTRE DO ET FOURNISSEURS relations verticales (client/ fournisseurs) se sont développés
Dans ce paragraphe nous présentons une typologie des modes [Alcouffe, 2001]:
de relation possibles entre DO/Fournisseur (Figure 1). Nous 1. relation classique de domination du donneur d'ordres (type
verrons que ces relations ne sont pas uniques : elles peuvent Boeing)
être verticales (de client à fournisseur), horizontales (entre 2. modèle plus coopératif (type Airbus)
concurrents), diagonales (entre complementeurs) et 3. rôle du donneur d'ordres limité à l’intégration d’ensembles
intersectorielles (entre partenaires de secteurs différents, nous achetés (donneurs d'ordre "architecte" type Bombardier).
ne détaillerons pas ce dernier type). Ces définitions ont été
proposées par [Ben Mahmoud et Calvi 2004]. Dans le cadre de la coopération verticale une typologie précise
Les coopérations intersectorielles : Il s’agit de coopérations le type de relation DO/Fournisseurs (Figure 1). Elle est fondée
entre entreprises appartenant à des secteurs totalement sur deux dimensions d’intégration du fournisseur en
différents réunis le temps d’un projet. conception collaborative : le « degré d’autonomie » laissé au
Les coopérations horizontales : Ces coopérations réunissent fournisseur dans le développement de son composant ou sous-
des entreprises concurrentes engagées dans un projet commun. système ainsi que le « risque » attaché à cette intégration vis à
Ces situations vont dépendre de la nature des ressources vis du projet final [Le Dain et al., 2007]. Les auteurs ont défini
apportées par chacun des partenaires, les enjeux de cette 5 niveaux d’autonomie possibles. Ces niveaux sont du plus bas
coopération pour ces acteurs, le degré de différenciation par les niveau, le niveau 0 et le niveau 1, où le fournisseur occupe une
partenaires du résultat final du projet, l’ampleur des place de simple exécutant, il est responsable de la fabrication
développements communs et du partage des réseaux de du produit et de son industrialisation. Son travail repose
distribution, par exemple, etc. essentiellement sur la base de spécifications techniques
détaillées (produit et process).
Dans les niveaux 2 et 3, le fournisseur participe à la conception cela nous allons exploiter l’ingénierie des exigences dans
à travers les plans et dessins issus du cahier des charges l’approche des exigences et utiliser la norme EIA 632 dans la
fonctionnel émis par le client (indications de rapports conception de systèmes. Surtout que cette norme offre des
coût/performance attendus, définition des interfaces…). processus des exigences et une forte approche dans sa
Ces deux niveaux sont presque similaires, la différence est que définition des systèmes complexes tels que ceux du domaine
dans le niveau 2 le client garde les droits de propriété aéronautique [Sahraoui et al., 2008].
intellectuelle sur les produits développés et que dans le niveau
3 le fournisseur garde la propriété intellectuelle de ses 3 IE ET SES PROCESSUS DES EXIGENCES
développements mais en assure la charge financière. Les compagnies dans les domaines de l’aéronautique [Abran et
Dans le niveau 4, le fournisseur est responsable de la al., 2007], l’électronique, la pharmaceutique et le génie logiciel
conception à la production, d’un composant sur la base d’un etc., insistent sur le fait que les exigences doivent être
cahier des charges fonctionnel. complètement « comprises » avant le développement du
Le niveau 5 représente le plus haut degré d’intégration du produit.
fournisseur, où il va participer à la définition du CDCF (cahier Etant donné les différents problèmes rencontrés durant le
des charges fonctionnel), et se voit confier un sous système développement, tels que la volatilité, la modification,
complexe incluant l’assemblage de sous-ensembles pour l’expression des exigences), les industriels ont trouvé la
lesquels il assurera la coordination des fournisseurs de rang 2. nécessité de développer l’ingénierie d’exigences [Sahraoui,
Le choix du mode de coopération verticale dépend du 2002], pour couvrir la gestion d’exigences durant tout le cycle
positionnement stratégique de l’ensemble des acteurs de vie du développement de systèmes : de l’élicitation jusqu’à
(DO/Fournisseur) par rapport à la typologie présentée. la validation finale.
2.2 Intégration des fournisseurs dés la phase exigences Les systèmes complexes tels que les avions, font toujours
Pour améliorer leur capacité à innover, leur temps de mise sur intervenir plusieurs parties prenantes qui doivent collaborer et
le marché des produits, et leur niveau de qualité, les DO partager le travail durant le projet. C’est dans ce sens que la
améliorent leurs capacités de développement de produit et de méthodologie développée par [Hellouin, 2002] vise à s'assurer
management de projet [Tang et Qian, 2008]. Ceci grâce aux que les exigences sont déclinées, allouées, suivies, satisfaites
progrès dans la conception assistée par ordinateur (CAD), la (en totalité, partiellement ou pas du tout), vérifiables, vérifiées
production assistée par ordinateur (CAM), l’ingénierie assistée et justifiées.
par ordinateur (CAE), l'ingénierie simultanée (CE), la gestion Les principales taches de l’IE concernent:
des données de produit (PDM), et la réingénierie de processus - l’identification des parties prenantes,
de Business (BPR). Jusqu’à ces dernières années où la gestion - l’élicitation des exigences,
du produit tout au long de son cycle de vie (PLM) a pris une - l’analyse des exigences,
part considérable dans cette course pour la réussite et - la formalisation des exigences,
l'innovation. - la vérification/ validation des exigences,
Le PLM peut être considéré comme une stratégie d'entreprise - la modification des exigences.
destiné à relier toutes les informations, les personnes et les
processus associés à un produit de la phase de l’élicitaion des
exigences ou le développement jusqu'à la fin de vie ou sa mise Modification
Elicitation des
exigences
des
au rebut. Le PLM peut être utilisé afin de faciliter exigences

l'intégration/l’implication des fournisseurs dans le Analyse des

exigences

développement de produits. Cette intégration ne sera pas

seulement une intégration technologique, mais aussi une Ingénierie

intégration dans le processus et l’organisation [Ameri et Dutta, Identification

des parties
des
exigences
prenante
2005]. En raison de son cycle de développement complexe,
Formalisation
l'industrie automobile a adopté l’intégration des fournisseurs des
exigences
dans le processus de développement qui se sont vu confiés un Vérification,
validation des
pourcentage de développement plus important [PTC, 2003]. exigences

Le DO et les fournisseurs ont tendance à optimiser leur propre

position au lieu de chercher à coopérer. Ce comportement n'est
pas basé sur les forces complémentaires. L’intégration des Figure 2. Objectifs de l’ingénierie des exigences [ELJ-06]
fournisseurs peut favoriser la créativité et l'innovation dans le
NPDP (projet de développement de nouveaux produits). 3.1 L’identification des parties prenantes
L’intégration des fournisseurs vise à créer une synergie grâce à La définition des parties prenantes est définie avant le
l'interaction entre les livrables et les résultats attendus entre les développement du système [Gilb, 2004], ce qui permet de
DO et les fournisseurs. définir les personnes liées au développement du système ainsi
Pour des développements futurs dans des domaines très qu’au projet. Alors, lorsqu’on commence à exécuter le
innovants, tel que les technologies hybrides, le travail en processus d’identification des parties prenantes, on répond
partenariat est inévitable. Le développement commun implique explicitement à la question: Qui fait Quoi ?
le partage des connaissances, les connaissances sur le système
développé ainsi que l'expérience tout au long du projet 3.1.1 Sélection des fournisseurs par le DO
représente une base d’expériences qui sera exploité dans les Dans un NPDP, le DO a besoin de fournisseurs pour pouvoir
projets futurs. mener à terme son projet. Le DO établi une base de donnée des
Dans ce travail, nous allons aborder l’aspect de l’intégration du différents fournisseurs et les classer selon des critères bien
fournisseur dés les premières phases du projet, celles où le définis (Tableau 1). Aussi cette base de données va évoluer
client final (utilisateur) commence à émettre ses besoins. Pour dans le temps et s’adapter à l’évolution probable des
fournisseurs (nouvelles compétences, nouvelles propositions Actuellement, plusieurs approches existent pour faciliter
technologiques, etc.). l’exécution de ce processus. Les travaux de [Coulin et al.,
Lorsque le DO développe un nouveau produit, la sélection de 2005], ont porté sur cet aspect de manière spécifique à travers
fournisseurs devient stratégique. le développement d’un outil « MUSTER ». Parmi les utilités
La capacité du fournisseur à offrir une innovation, une de cet outil, permettre à l’utilisateur d’introduire toutes les
nouvelle idée, peut être un facteur clé dans ce choix. exigences en langage naturel pour ensuite les catégoriser en
Etant donné que la proximité du fournisseur ainsi que sa fonction de mots clés. Mais ce n’est toujours pas un processus
culture sont un avantage dans la collaboration, dans notre automatique, surtout que les exigences sont exprimées en
projet les fournisseurs locaux envisagent de s’associer et langage naturel et leur formalisme n’est pas évident. Ici le
d’évoluer pour se mettre en capacité d’innover. système PLM vu à travers des processus automatique qui
repose sur l’échange d’informations via le réseau informatique
Tableau 1. Critère de sélection des sous-traitants par exemple se trouve limité. La plupart des chercheurs
pensent que ce processus doit obligatoirement contenir deux
N° Critère de sélection Ordre d’ importance types de méthodes : « Brainstorming » (séance de réflexion) et
1 Le prix Interview.
2 Les délais de livraison A: Produit 3.2.1 « Brainstorming »
3 La qualité
La première méthode d’élicitation des exigences, est la séance
de réflexion (brainstorming). Cette méthode est efficace du fait
4 La capacité de production qu’elle permet d'obtenir des idées intéressantes et claires. Pour
5 La capacité technique que la session de réflexion soit efficace, la plupart des
6 L’expertise B: Processus chercheurs du domaine de l’ingénierie des exigences sont
d’accord sur le fait de préciser l’objectif de chaque session
7 Le respect des procédures
[Robertson et Robertson, 2004], puis regarder des exemples de
8 Les normes de qualité produits semblables.
9 La reputation Durant la session les idées sont numérotées pour que les
10 La performance passée
participants puissent s’y référer facilement, les expliciter ;
C: Historique et Chaque idée quel que soit son origine pourrait être pertinente,
11 La situation financière si toutefois elle sert l’objectif final de la session. Dans
situation actuelle
12 Le volume antérieur des échanges [Robertson et Robertson, 2004], les auteurs ont précisé
13 La localisation géographique l’importance de l’utilisation des tableaux, des papiers, de la
numérotation de toutes les idées et suggèrent l’écriture des
14 L’échange d’information
D: Aspects idées sur des tableaux.
15 La réciprocité stratégiques
(Direction Générale) 3.2.2 Interview
16 L’innovation
La deuxième méthode d’élicitation des exigences utilise les
interviews. Cette méthode est très répandue dans le milieu
En effet lors de la sélection des fournisseurs qui vont participer industriel. Elle n’exige pas trop de temps, contrairement à la
en projet, les ingénieurs du DO (affecté au projet) vont séance de réflexion. Ce gain en temps est dû au fait que la
s’assurer de la compétence des fournisseurs pour collaborer et plupart des personnes qui l’utilisent sont des spécialistes
innover. Cette aptitude peut permettre à des fournisseurs qui ne d'analyse commerciale ou des ingénieurs des exigences déjà
remplissent pas efficacement les critères de fabrication, de familiers avec ce type de méthode [Eljamal, Sahraoui, 2005].
livraison ou de prix mais qui ont un apport majeur au niveau Cette méthode exige des compétences en ingénierie des
de l’innovation d’être sélectionnés [Allmann et al., 2006]. Ceci exigences de la part des fournisseurs, ce qui n’est pas évident
revient à établir aussi une dynamique de critères de sélection et dans le cas des PME. Lorsque celles-ci réalisent des systèmes
qui reposera sur le choix des plusieurs département tel que les simples, elles n’ont actuellement pas ressenti le besoin de
achats, le R&D où par exemple les ingénieurs auront plus de développer ces compétences en interne.
poids lors de la phase exigences. 3.3 L’analyse des exigences
3.2 L’élicitation des exigences L’analyse des exigences vient après la phase d’élicitation.
Cette phase vient après celle de l’identification de toutes les Cette phase se traduit par le lancement du processus d'analyse
parties prenantes, elle consiste à exécuter le deuxième des exigences en étudiant l’ensemble des exigences soumises
processus de l’ingénierie des exigences qui est le processus par les parties prenantes afin de les analyser, les compléter, les
d’élicitation des exigences [Sahraoui, 2002]. trier, les tracer, éliminer l’ambiguïté et les redondances entre
Durant cette phase nous essayons de répondre à la question exigences [Maciaszek, 2001]. Le résultat de l’analyse sera un
“que doit faire le système?” et non pas “comment faut-il le document cohérent, présenté en langage naturel (avec parfois
faire ?”. Ceci revient à traduire en attentes un besoin ressenti. des diagrammes UML) [Eljamal, Sahraoui, 2005].
Ce processus d'élicitation des exigences est souvent vu par L’importance de la spécification des exigences est due au fait
beaucoup de chefs de projets comme trop laborieux, trop long, qu’elle engage la quasi-totalité du coût du système. C’est
ou trop difficile à entreprendre. Il est quelque fois négligé souvent à ce niveau du projet que se joue la rentabilité pour le
comme si les exigences sont déjà présentes, et qu’il suffit de maître d’œuvre, et la satisfaction pour le maître d’ouvrage
les exprimer. Cependant, si les exigences sont intangibles, [Eljamal, Sahraoui, 2005]. Plusieurs projets connaissent des
contradictoires, ou imprécises, il devient très difficile d’estimer échecs, suite à des spécifications non stables et non validées.
le temps nécessaire à leur correction durant la conception et Les échecs au niveau de la mise en œuvre sont presque
l'implémentation. toujours dus à une spécification inadéquate et à une mauvaise
exécution du processus d’analyse des exigences.
Ce processus est très critique car il conditionne tout le cycle de 3.6 La modification des exigences
développement du système. C’est à ce niveau qu’il faut Le but de ce processus est de gérer les demandes de
détecter la majorité des erreurs, faute de quoi la suite du modifications. La demande de modification peut venir soit du
développement serait compromise. L’intégration du DO, soit du Fournisseur ou bien de l’utilisateur. Ceci va
fournisseur devient stratégique, lorsqu’il est amené à réaliser conduire à la recherche des exigences affectées par la demande
des éléments (modules) du produit final en réponse à une de modification, quelle partie de conception (implémentation)
partie des exigences. Ainsi, plus la qualité de ce processus sera sera affectée ? Lors de cette phase il est évident que les parties
prise en considération plus la qualité du produit sera améliorée. prenantes doivent s’impliquer afin d’établir une étude d’impact
En particulier la prise en compte des opportunités et de la demande de changement? Et voir comment intégrer la
contraintes induites par les fournisseurs peut être une source de demande dans le cycle de développement ?
valeur ajoutée et d’innovations. Concernant l’étude d’impact nous citons les travaux de
3.4 La formalisation des exigences [Eljamal, 2006] où l’auteur s’est intéressé à l’impact du
changement d’exigence sur la sécurité du système où il a établi
Le processus de formalisation des exigences permet d’avoir
des invariants qui permettront de ne pas modifier les exigences
une solution satisfaisant l’ensemble des exigences soumises
affectant la sécurité. Dans notre article nous n’aurons pas
par les parties prenantes. Cela revient à répondre à la question
d’invariants étant donné que l’impact du changement affecte
"Que doit faire le système ?" Et cela tout au long de son cycle
les outils d’assemblage, et que les invariants ne favorisent pas
de vie. La phase d’analyse produit un modèle du système
l’innovation.
répondant exactement aux exigences du produit à développer.
En effet, une exigence peut être décrite par de nombreux
4 LA CONCEPTION DU SYSTEME
modèles, et satisfaite par plusieurs technologies. Quant aux
technologies, elles peuvent être proposées par différents La conception de tout système repose sur les exigences émises
fournisseurs existants dans le marché. La représentation de au départ. Les processus de conception du système sont utilisés
l’exigence se différentie d’un métier à un autre. Par exemple, pour convertir les exigences de l'acquéreur ou autres parties
pour le logiciel, les développeurs utilisent des représentations prenantes en un ensemble de réalisations des produits qui
formelles, basées sur des notations mathématiques (VDM, répondent aux attentes.
RAISE,…). Tandis que, dans d’autres domaines comme celui Deux processus sont impliqués : la définition des exigences et
de l’électricité et de l’électronique, on trouve l’utilisation des la définition de solutions. La relation de ces processus est
schémas électroniques (Max+, Orcad), et pour les systèmes illustrée dans la figure (figure 3).
Exigences de l’acquéreur et des autres parties prenantes
temps réel les développeurs et les analystes proposent encore
d’autres solutions [Schwarz et al., 1991].
En effet, la notation du modèle est très importante afin que Processus de
Définition
l'équipe de réalisation et les constructeurs puissent comprendre Des exigences Conflits & Issues
et contribuer facilement au contenu du modèle. Ici le système Des exigences
Exigences techniques
PLM prend place majeure surtout du fait que l’échange De Validation du système
Caractéristiques
d’informations se fait de manière systématique. Actuellement, Du produit
processus
on utilise de plus en plus de représentations graphiques du De définition
de la Solution
système, telles que les diagrammes d’UML, data flow diagram,
SysML... qui doivent être assez rigoureuses pour que les
réalisateurs puissent comprendre précisément les exigences. Spécification, schémas, Modèles
Généralement, un modèle résulte de plusieurs vues. La vue
Figure 3. Les processus de conception de systèmes selon la
opérationnelle, décrit le niveau des services rendus aux
norme EIA-632
utilisateurs et les conditions d’utilisation et d’exploitation du
système. La vue fonctionnelle décrit ce que doit faire le
Le processus de conception a pour but de convertir les
système pour exécuter sa mission en répondant aux exigences
exigences convenues avec l'acquéreur en un ensemble de
opérationnelles, c’est-à-dire les fonctions et leurs
produits réalisables. Il est divisé en sous processus :
performances. En fin la vue physique traduit les contraintes
- processus de définition des exigences. Les entrées du
techniques imposées au système, notamment les
processus de définition des exigences sont de deux types : (1)
caractéristiques physiques et les interfaces avec
les exigences venant du contrat (2) les exigences venant
l’environnement naturel technique et humain. Cette vue
d'autres processus tels que les plans techniques. Ce processus
apparaît dans les phases avancées de la modélisation.
est utilisé pour obtenir les exigences techniques du système.
3.5 La vérification/ validation des exigences Ces exigences représentent une description raisonnablement
La vérification consiste à vérifier que la conception correspond complète du problème qui doit être résolu pour fournir un
aux exigences du système, et que l’implémentation correspond ensemble de produits finaux dans le but de répondre aux
à son tour à la conception développée et proposée par les exigences de l’acquéreur et des autres parties prenantes. Ce
développeurs. Le processus de vérification est intégré aux processus reste incomplet du fait des changements de contrat
différentes phases du développement du système. Par contre, la qui surviennent, ou de l’identification d’autres exigences de la
phase de validation met en jeu les parties prenantes part des parties prenantes qui affectent la conception des
(utilisateurs, exploitants, donneur d’ordre, chef de projet, produits (produit final ou les produits permettant d’avoir ce
équipe d’analyse système, fournisseurs) pour valider les dernier tels que le système de production, outils
exigences après la réalisation du système prévu par rapport aux d’assemblages, etc.),
attentes utilisateurs, aux contraintes du programme du maître - processus de définition de la Solution. Le processus de
d’ouvrage, aux contraintes du projet et de l’entreprise et aux définition de la solution permet d’obtenir une solution de
contraintes externes. conception d’un produit final acceptable. La solution proposée
doit satisfaire : (1) les exigences techniques du système
provenant du processus de définition des exigences, (2) les Le diagramme de cas d’utilisation (figure 6) décrit l'interaction
exigences techniques dérivées de ce même processus. entre les acteurs et le système durant la phase des exigences du
A travers les processus de conception nous remarquons projet. Dans ce cas nous constatons que le fournisseur d’outils
l’intrication entre la définition des exigences et la définition de d’assemblage est impliqué dés la phase d’analyse des
la solution (fonctionnelle, physique). exigences de l’utilisateur final. Ainsi il participe à la phase de
Dans la (Figure 4), le schéma de gauche représente la formalisation des exigences où il aura une plus grande force de
configuration actuelle de la relation DO/fournisseur lors de proposition et plus de marge d’innovation. Ceci est grâce au
l’émission du client final de ses exigences. Nous constatons fait qu’il ne sera pas réduit à exécuter le cahier des charges
que le fournisseur n’intervient sur le développement qu’avec le venant du DO mais il sera au même niveau d’analyse que ce
DO, qui devient sont interlocuteur avec le client final dans dernier et ainsi pouvoir adapter ses outils d’assemblage.
l’expression des exigences.
<<Uses>>
Interview <<Uses>> Brainstorming
Elicitation
Client final des exigences

Identification des
Exigences Client final parties prenantes

Emet DO (R&D,
Reçois
valide Analyse Production,…)
DO des exigences
Exigences
Reçois Valide
propose Formalisation
Exigences Valide Reçois
des exigences
DO Propose Fournisseur
Utilisateur du
produit (pilote,
Fournisseur équipes de tests,…) Vérification
et validation Fournisseurs
des exigences
(outil d’assemblage)
Figure 4. Modèle proposé
Modification
Le modèle proposé (Figure 4) partie droite, permet le passage des exigences

d’une configuration séquentielle vers une configuration

dynamique. Lors du choix des solutions le modèle permet une Figure 6. Le cas de définition des exigences
force de proposition puisque le fournisseur interagis avec le
DO et le client final dés les premières phases du cycle de vie Dans le cas de notre projet, les fournisseurs interviennent
du produit. indirectement dans le processus de fabrication du produit final.
La partie droite de la (Figure 4) détaille le modèle où nous Ils offrent les outils d’assemblage utilisés durant les phases de
remarquons que le fournisseur reçoit les exigences émises par fabrication ou d’assemblage. La particularité de ces outils est
le client final et interagis tout en ayant la possibilité de valider qu’ils sont spécifiques pour chaque tronçon et modèle d’avion.
ou non les exigences qu’il peut réaliser. Ceci lui permet aussi Donc spécifiques pour chaque système ou sous système du
de proposer des réponses à des exigences autres que celles qui produit final.
lui sont attribuées. Cette étape permet des innovations, Dans la procédure habituelle le DO envoi le cahier des charges
l’autonomie du fournisseur et surtout son implication dans la technique aux fournisseurs qui doivent réaliser les outils
résolution des conflits des exigences très tôt dans le cycle de spécifiques et adaptables aux situations de production ou
vie du produit. Ainsi, nous allons vers une meilleur d’assemblages ce qui revient à réaliser fréquemment des
compréhension et interprétation des exigences puisqu’elle sera études, au cas par cas. Aussi, un des problèmes rencontrés par
faite par les parties concernées tout en évitant au maximum les les fournisseurs est celui de modification des exigences qui
interlocuteurs (figure 5). leur parvient tardivement et qui les met dans des positions
délicates.
Exigences
Un des instants critiques du processus de gestion des exigences
DO Fournisseur
est celui de la modification. La modification d’une exigence
Identification
des parties
peut avoir un impact sur tout le projet et entraîner des retards
prenantes
Client final
considérables, surtout quand elle est faite tardivement. Nous
Client final Modification Elicitation allons détailler cet aspect à travers le diagramme de cas
des des
Exigences exigences exigences Exigences
d’utilisation. La modification des exigences est toujours
DO Fournisseur
DO Fournisseur présente dans un projet de conception, étant donnée les
itérations tout au long du projet pour converger vers la
Verification
Analyse Client final solution.. L’interaction entre les parties prenantes durant la
Validation
Client final Des
des
exigences
phase de modification des exigences implique le DO, le client
Exigences
exigences
Exigences DO Fournisseur
final et le fournisseur (figure 7). Nous allons maintenant
Formalisation
DO Fournisseur Des détailler la partie où la modification est faite et les parties
exigences Client final
prenantes qui y interviennent.
Exigences
L’initiateur de la demande de changement peut être soit le
DO Fournisseur
client final qui est l’utilisateur, soit un membre du projet
Figure 5. Modèle d’interaction tout au long du cycle des (ingénieur, département achat, etc.), le cas habituel de notre
exigences projet. Ici nous détaillons la phase de modification des
Le système PLM assurera l’échange des données, mais lors de exigences, où le développeur et l’évaluateur font partie des
la phase d’élicitation des exigences les « interviews » et les personnes affectées au projet, sachant que l’équipe du projet
« brainstormings » restent indispensables et plus efficaces que est constituée des personnes appartenant au DO et au
les échanges d’informations via les systèmes informatiques. fournisseur réunies au cours projet.
Nous constatons aussi l’existence de deux processus des de type SI qui permettent l’échange de données et la gestion
exigences le premier est celui de l’exigence émise par des modifications importantes et nombreuses lors de ces
l’acquéreur et qui constitue le cycle des exigences du produit phases. L’ensemble de ces éléments peut nécessiter une
final (avion). Le deuxième est celui de l’exigence émise par le coopération entre fournisseurs de type diagonale.
DO (développeur) qui constitue le cycle des exigences du Dans cette démarche le DO, aura une évaluation plus large de
produit permettant d’avoir le produit final (outils son fournisseur à travers le critère d’adaptabilité du fournisseur
d’assemblages). Le premier processus est le déclencheur du aux nouvelles exigences.
deuxième. Lors de la décomposition du système chaque partie prenante va
La décomposition du système revient à le décomposer en deux se focaliser sur sa partie afin d’évaluer l’impact du
systèmes principaux, le premier sera le produit final et le changement.
deuxième sera les produits permettant. Le produit final est Dans nos perspectives nous envisageons l’utilisation de
l’avion dans notre cadre de projet. Le système avion sera SysML lors de la modélisation, et exploiter le diagramme des
décomposé à son tour en sous systèmes jusqu'à l’obtention du exigences qu’il offre.
produit élémentaire. Les produits permettant sont les produits
qui nous permettent l’obtention du produit final, ce sont les 6 REFERENCES
produits qui permettent le développement, le support, la Abran, A., Meridji, K., Dolado, J., (2007) Software
production etc. Le produit permettant qui nous intéresse dans Engineering from an Engineering Perspective: SWEBOK
ce projet est les outils d’assemblage. as a Study Object, ADIS WORKSHOP – CEDIS 2007
Zaragoza (Spain).
Actualite, (2007) http://actualite.aol.fr/ economie/toyota-
Décomposition maintient-ses-objectifs-pour-2007 / 539039/p-article_cat
du système
<<Uses>>
/article_titre/ article_id / article.html.
Développeur
Application de la
(DO, Fournisseur)
Alcouffe, C., (2001) Formes de coopération interentreprises :
demande de
changement l'organisation de la R & D dans l'aéronautique et le spatial,
Demandeur <<Includes>> <<Includes>> rapport LIRHE - Unité mixte de recherche CNRS/UT1.
(Utilisateur, DO,
Fournisseur)
Allmann, C., Winkler, L., Kölzow, T., (2006) The
Initialisation Evaluation de
de la demande l’impact
Requirements Engineering Gap in the OEM Supplier
Relationship, Journal of Universal Knowledge
Evaluateur
<<Includes>> (Fournisseur des Management, vol. 1, no. 2, 112-122.Ameri, F., Dutta. D.,
outils d’assemblage)
Analyse de l’impact (2005) Product Lifecycle Management: Closing the
sur le système d’outils
d’assemblage
Knowledge Loops”, Computer-Aided Design &
Applications, Vol. 2, No. 5, pp 577-590.
ANSI/EIA-632., (1998) Processes for engineering a system,
Approved 7 January 1999, Reaffirmed 2003.
Figure 7. le cas de changement d’exigences
Ben Mahmoud J.S., Calvi R., (2004) Les coopérations
interentreprises dans les projets de développement. Chap 8,
Comme illustré dans la (figure 7), la décomposition du
In Garel G., Giard V., Midler C. Faire de la recherche en
système est faite par les développeurs coté système final le
management de projet, Paris, Vuibert Fnege , pp. 161-188.
DO, et côté outils d’assemblage se trouve le fournisseur.
Berio, G., Benali, K., Boudjlida, N., Petit, M., (2004) A
Concernant l’évaluation de l’impact, la (figure 7) ne représente
Unified Enterprise Modelling Language for Enhanced
que le fournisseur car nous ne nous intéressons qu’à l’impact
Interoperability of Enterprise Models. 11th IFAC
de l’exigence sur les outils d’assemblage. Ici le fait
Symposium on Information Control Problems in
d’impliquer le fournisseur dans le projet dès cette phase lui
Manufacturing, INCOM'04, Salvador, Brazil.
permettra d’évaluer l’impact de modification d’exigences sur
Cimdata, http://www.cimdata.com/
ses outils d’assemblage et d’intervenir à travers la validation
Coulin, C., ZowghiI, D., Sahraoui, A.E.K., (2005) Towards a
ou non de cette nouvelle exigence (voir le modèle proposé
collaborative and combinational approach to requirements
dans la figure 4, valide est de type booléen donc il prend deux
elicitation within systems engineering framework “,18th
états, validé ou non validé).
International Conference on Systems Engineering
(ICEng'05), pp.456-461, Las Vegas (USA).
5 CONCLUSION
Eljamal, M.H., Sahraoui, A.E.K., (2005) Towards a
Le fournisseur doit être impliqué tôt dans le processus de methodology for requirements evolution and impact on
gestion des exigences, pour permettre de prévoir les bons safety requirements, 6ème Congrès International
outils bien avant le lancement de la production (l’assemblage) Pluridisciplinaire "Qualité et Sûreté de Fonctionnement"
et favoriser l’innovation produit et process. (QUALITA 2005), pages.117-124, Bordeaux (France).
L’ingénierie des exigences permet au fournisseur de gérer El Jamal, M.H, (2006) Contribution à l'évolution des exigences
correctement les changements attendus par le DO et au-delà, et son impact sur la sécurité, Thèse, LAAS-CNRS,
de participer à la définition des exigences avec l’utilisateur. Université Paul Sabatier - Toulouse III. Foufou, S., Fenves,
Cela lui permet d’anticiper les attentes du DO, et d’être force S., Bock, C., Sudarsan, R., Sriram, R.D. (2005) A Core
de proposition dans la définition des exigences avec le DO. Product Model for PLM with an Illustrative XML
Les fournisseurs sont impliqués, non seulement dans le projet, Implementation, Proceedings of the International
mais développent des compétences dans la conception de Conference on PLM, Lyons, France.
système (outil d’assemblage) et peuvent aussi adapter leurs Gilb, K., (2004) Evolutionary Project Management & Product
solutions à d’autres clients sur d’autres marchés. Cela implique Development.
aussi de nouvelles organisations avec l’identification des Ghodsypour, S.H., O’Brien, C., (2001) The total cost of
interlocuteurs pour les chefs de projet, L’utilisation des outils logistics in supplier selection, under conditions of multiple
 sourcing, multiple criteria and capacity constraint, automata based elicitation and related issues, International
International Journal of Production Economics, 73, 15–27. Conference on Software Engineering Research and Practice
Hellouin, L., (2002) Contribution à l’ingénierie des exigences (SERP'02), Las Vegas (USA).
et à la traçabilité, PhD Thesis, LAAS-CNRS and INPT. Sahraoui, A.E.K., Buede, D.M., Sage, A.P., (2008) Systems
Impactvirtuel, (2007) http://www.inpactvirtuel.com/news/ engineering research, Journal of Systems Science and
13385-PS3-Mars-2007.html. Systems Engineering, Vol.17, N°3, pp.319-333.
Le Dain, M.A., Calvi, R., Sandra, C., (2007) Proposition d’un Schwarz, J. J., Skubich, J. J., Aubry, R., (1991) Lacatre: The
modèle d’évaluation de la performance fournisseur en basis for a Real Time Software Engineering Workshop,
conception collaborative, 7e Congrès International de Informatik-Fachberichte; Vol. 295, Workshop über
Génie Industriel– Trois-Rivières, Québec (CANADA). Realzeitsysteme, 12. Fachtagung des PEARL-Vereins e.V.
Maciaszek, L. A., (2001) Requirements Analysis and System Pages: 20 - 40, Springer-Verlag, London, UK.
Design, Person Education Limited, Harlow, England. Sudarsan, R., Han, Y. H., Foufou, S., Feng, S. C., Roy, U.,
Nilsson, P., Fagerstrӧmb, B., (2006) Managing stakeholder Wang, F., Sriram, R. D., Lyons, K., (2006) A Model for
requirements in a product modelling system, Computers in Capturing Product Assembly Information, Journal of
Industry 57, 167–177. Computing and Information Science in Engineering, 6(1):
Nordin, F., (2006) Identifying intraorganisational and 11-21, ASME.
interorganisational alliance conflicts—A longitudinal study Tang, D., Qian. X., (2008) Product lifecycle management for
of an alliance pilot project in the high technology industry, automotive development focusing on supplier
Industrial Marketing Management 35 116– 127. integration,Computers in Industry 59 288–295.
Patil, L., Sriram, R.D., (2005) Ontology Formalization of Xiao-li, Q., Hong, Y., Xi-ying, W., Ming-yuan, C., (2002)
Product Semantics for Product Lifecycle Management, Information shares of network manufacturing system based
NISTIR 7274. on STEP and XML, Journal of computer integrated
PTC (2003) Product Development System: Product Lifecycle Manufacturing system (Chinese), vol. 8, no. 7.
Management for Manufacturing Companies, Zowghi, D., Nurmuliani, N., (2002) A Study of the Impact of
http://www.ptc.com/go/pds. Requirements Volatility on Software Project Performance,
Robertson, S., Robertson, J., (2004) Requirements-Led Project 9th Asia-Pacific Software Engineering Conference, Gold
Management: Discovering David's Slingshot, Wesley. Coast, Australia.
Sahraoui, A.E.K., (2002) Requirements engineering: the