Tyu

n vue de I'obtention du
UOC1OkA1 UL L'UH|vLkS|1L UL 1OULOUSL

DeIivre par :

DiscipIine ou speciaIite :

Presentee et soutenue par :

7itre :

1URY

coIe doctoraIe :
Unite de recherche :
Directeur(s) de 7hese :
Rapporteurs :
Ie :
Institut National Polytechnique de Toulouse (INP Toulouse)
Systmes (EDSYS)
Approche gnrique pour la modlisation et l'implmentation des processus.
vendredi 11 fvrier 2011
Jean-Stphane ULMER
Systmes industriels
Jean-Pierre Belaud
Herv Pingaud
Pascale Zarate
Bruno Traverson
Xavier Boucher
Jean-Claude Bocquet
Jean-Marc Le Lann
Laboratoire de Gnie Chimique UMR 5503
iii
Rsum
Une entreprise doit tre capable de dcrire et de demeurer ractive face un vnement
endogne ou exogne. Une telle flexibilit peut s'obtenir par la gestion des processus d'entreprise
(Business Process Management - BPM). Lors d'une dmarche BPM, diffrentes transformations
interviennent sur les modles de processus dvelopps par l'analyste mtier et l'expert en technologies
de l'information. Un non-alignement se cre entre ces modles htrognes lors de leurs manipulations :
il s'agit du "foss mtier-TI" tel que dcrit dans la littrature. L'objectif de notre travail est de proposer un
cadre mthodologique permettant un meilleur pilotage des processus mtier, afin de tendre vers un
alignement systmatique de leur modlisation leur implmentation au sein du systme cible. A l'aide de
concepts issus de l'ingnierie d'Entreprise et des Systmes d'Informations dirige par les modles et des
TI, nous dfinissons une dmarche gnrique assurant une cohrence intermodle. Son rle est de
conserver et de fournir toutes les informations lies la structure et la smantique des modles. En
permettant la restitution intgrale d'un modle transform au sens de l'ingnierie inverse, notre
plateforme permet une synchronisation entre modle d'analyse et modle d'implmentation. Le manuscrit
prsente galement l'adquation possible entre l'ingnierie des procds et le BPM travers un point de
vue multi-chelle.
Mots-cls
Ingnierie de systmes d'information - Gestion des processus d'entreprise - Business Process
Modeling Notation - Ingnierie dirige par les modles - Alignement de modles Mtamodlisation -
Gnie des procds

v
Remerciements

Ces quelques lignes marquent le point final de ce travail de thse ainsi que laboutissement de
trois annes (et quelques mois) de recherche, de dcouvertes et de collaborations ralises au sein du
dpartement Procds et Systmes Industriels du Laboratoire de Gnie Chimique.
Ce travail de thse a t accompli sous la direction de Messieurs Jean-Pierre Belaud, Matre de
Confrence au dpartement PSI, et Jean-Marc Le Lann, Professeur dUniversit et directeur de
lENSIACET. Je tiens particulirement les remercier de mavoir permis davoir la plus libert dans la
conduite de mes travaux et encourag dans cette difficile dmarche consistant explorer des approches
nouvelles la frontires entre disciplines distinctes.
Je remercie mes rapporteurs pour toute lattention quils ont port ma thse : Messieurs Xavier
Boucher, Professeur associ lENSM et Jean-Claude Bocquet, Professeur dUniversit et directeur du
LGI de lEcole Centrale Paris. Je remercie galement les membres du jury : Monsieur Herv Pingaud,
Madame Pascale Zarat, et Monsieur Bruno Traverson, qui me font lhonneur de discuter de mon travail
et participer ce jury.
Je remercie toutes ces personnes que jai rencontres au cours de ces trois annes de thse, aux
thsards et lambiance cosmopolite qui rgne au sein du LGC PSI. Je tiens spcialement remercier
Mujtaba Agha et ses pauses-djeuner base de chips et soda, El-Awady Attia pour son coute, ses
questions et le caf, et Jess Manuel Barragan Ferrer pour ses conseils aviss sur les mthodes et les
techniques de travail.
Jaimerais exprimer toute ma gratitude envers mes parents, Luzviminda et Laurent, pour leur
soutien dans la ralisation de mes tudes, leurs encouragements et leurs conseils aviss dans tous mes
choix, pour mavoir transmis leur motivation et leur volont, essentielles cette aventure. Maraming
salamat po !
Enfin, jaimerais remercier tout particulirement Sylvie, pour ton indfectible prsence et affection.
Tu as russi me supporter pendant ces dernires tapes difficiles de la ralisation de cette thse. Je
ten serai ternellement reconnaissant.

vii
Sommaire
A. PREAMBULE ....................................................................................................................................................... 15
1. INTRODUCTION ....................................................................................................................................................17
1.1 CADRE DES TRAVAUX DE RECHERCHE .......................................................................................................................18
1.2 PRESENTATION DU MANUSCRIT ..............................................................................................................................19
2. CONTEXTE ET PROBLEMATIQUE ................................................................................................................................23
2.1 CONTEXTE ........................................................................................................................................................24
2.2 PROBLEMATIQUE ...............................................................................................................................................27
2.3 OBJECTIFS DE RECHERCHE .....................................................................................................................................29
B. CADRE METHODOLOGIQUE ................................................................................................................................ 31
3. DE LENTREPRISE AU PROCESSUS ...............................................................................................................................33
3.1 ENTREPRISE ......................................................................................................................................................34
3.2 SYSTEME DINFORMATION ....................................................................................................................................36
3.3 MODELISATION DENTREPRISE ...............................................................................................................................38
3.4 CADRE DE MODELISATION DENTREPRISE ..................................................................................................................39
3.5 CONCLUSION .....................................................................................................................................................42
4. NOTIONSAUTOUR DU TERME PROCESSUS .............................................................................................................43
4.1 PROCESSUS .......................................................................................................................................................44
4.2 PROCESSUS MTIER .............................................................................................................................................45
4.3 CYCLE DE VIE ET ACTEURS .....................................................................................................................................49
4.4 MODELISATION PAR LES PROCESSUS : IMPORTANCE DE LA VUE FONCTIONNELLE ..................................................................50
4.5 CONCLUSION .....................................................................................................................................................51
5. INGENIERIE ET ARCHITECTURE DIRIGEESPAR LESMODELES .............................................................................................53
5.1 INGENIERIE DIRIGEE PAR LES MODELES .....................................................................................................................54
5.2 ARCHITECTURE DIRIGEE PAR LES MODELES.................................................................................................................55
5.3 CONCLUSION .....................................................................................................................................................59
6. INGENIERIE DES PROCESSUSMETIER ...........................................................................................................................61
6.1 DE LA GESTION DU WORKFLOW A LA GESTION DES PROCESSUS METIER ..............................................................................62
6.2 LE CYCLE DE VIE DU PROCESSUS SELON LAPPROCHE BPM .............................................................................................64
6.3 DU MDA AU BPM ............................................................................................................................................67
6.4 SUITES BPM .....................................................................................................................................................68
6.5 LES LIMITES DU BPM ..........................................................................................................................................72

viii
6.6 CONCLUSION .....................................................................................................................................................72
C. DEFINITION DE LAPPROCHE............................................................................................................................... 75
7. DE LA NECESSITE DE LAPPROCHE ..............................................................................................................................77
7.1 VERS UN ALIGNEMENT OPERATIONNEL .....................................................................................................................78
7.2 HETEROGENEITE ET DIFFERENTES ABSTRACTIONS .........................................................................................................81
7.3 CONCEPTS ET APPROCHES POUR UNE GESTION AGILE....................................................................................................82
7.4 CONCLUSION .....................................................................................................................................................86
8. CARACTERISATION ................................................................................................................................................89
8.1 VERS UNE APPROCHE CENTREE PIVOT .......................................................................................................................90
8.2 VUES...............................................................................................................................................................91
8.3 GENERICITE ......................................................................................................................................................92
8.4 ACTEURS ..........................................................................................................................................................92
8.5 DONNEES .........................................................................................................................................................92
8.6 CONCLUSION .....................................................................................................................................................96
9. CONCEPTION .......................................................................................................................................................97
9.1 CONFORMITE ENTRE MODELE ET METAMODELE ..........................................................................................................98
9.2 DE LA TRANSFORMATION DE MODELES BIDIRECTIONNELLES A LA NOTION DE PIVOT ............................................................ 100
9.3 TRANSFORMATIONS HORIZONTALES, TRANSFORMATIONS VERTICALES ET INTEROPERABILITE ................................................. 103
9.4 METAMODELE ET METAMODELES PIVOT ................................................................................................................. 104
9.5 DEFINITION DU METAMODELE PIVOT ..................................................................................................................... 107
9.6 CARACTERISATION DES LIENS SEMANTIQUES ............................................................................................................ 115
9.7 FORMATION DES METAMODELES BPA ET BPI .......................................................................................................... 116
9.8 CONCLUSION ................................................................................................................................................... 117
D. MISE EN UVRE ............................................................................................................................................... 119
10. PLATEFORME SOLUTION POUR UNE COHERENCE ET UN ALIGNEMENT DESPROCESSUS- SCALP ............................................ 121
10.1 ARCHITECTURE GENERALE DE LA PLATEFORME SCALP ............................................................................................... 122
10.2 ENVIRONNEMENT PIVOT .................................................................................................................................... 122
10.3 ENVIRONNEMENT DE MODELISATION ..................................................................................................................... 125
10.4 ENVIRONNEMENT DIMPLEMENTATION .................................................................................................................. 126
10.5 IMPLEMENTATION DES MAPPINGS ET TRANSFORMATIONS ........................................................................................... 129
10.6 CONCLUSION ................................................................................................................................................... 134
11. DEMONSTRATION ............................................................................................................................................... 137
11.1 PRESENTATION DU PROCESSUS ETUDIE ................................................................................................................... 139

ix
11.2 SCENARIO DE VALIDATION................................................................................................................................... 139
11.3 PREMIERE PHASE : DU DIAGRAMME DE PROCESSUS AU MODULE ERP............................................................................. 143
11.4 DEUXIEME PHASE : DU MODULE ERP AU DIAGRAMME DE PROCESSUS ............................................................................ 149
11.5 TROISIEME PHASE : DU DIAGRAMME DE PROCESSUS AU MODULE ERP ........................................................................... 154
11.6 CONCLUSION ................................................................................................................................................... 155
12. INGENIERIE DES PROCESSUSAU SERVICE DE LINGENIERIE DESPROCEDES........................................................................... 157
12.1 NOTIONS AUTOUR DE LINGENIERIE DES PROCEDES ................................................................................................... 158
12.2 VERS UNE APPROCHE PROCESSUS-PROCEDE ............................................................................................................. 159
12.3 CONCLUSION ................................................................................................................................................... 163
E. EPILOGUE ......................................................................................................................................................... 165
13. CONCLUSION ET PERSPECTIVES ............................................................................................................................... 167
13.1 CONCLUSION ................................................................................................................................................... 167
13.2 BILAN ............................................................................................................................................................ 168
13.3 SYNTHESE DES CONTRIBUTIONS ............................................................................................................................ 170
13.4 LIMITES ET PERSPECTIVES .................................................................................................................................... 171
14. BIBLIOGRAPHIE .................................................................................................................................................. 175
15. ANNEXES .......................................................................................................................................................... 185
15.1 GLOSSAIRE ..................................................................................................................................................... 186
15.2 TRADUCTION DES TERMES ANGLOPHONES ............................................................................................................... 190
15.3 ACRONYMES ................................................................................................................................................... 192
15.4 DEMONSTRATION : EXTRAITS DE FICHIERS ............................................................................................................... 194
15.5 SOMMAIRE DETAILLE ......................................................................................................................................... 203

xi
Table des figures
FIGURE 1. PRINCIPAUX THEMES DE RECHERCHES .....................................................................................................................18
FIGURE 2. CONTEXTE SCIENTIFIQUE DES TRAVAUX DE RECHERCHE ................................................................................................19
FIGURE 3. CARICATURE DE LA CONCEPTION DUN SYSTEME ........................................................................................................19
FIGURE 4. PRESENTATION DUNE PARTIE ...............................................................................................................................20
FIGURE 5. STRATEGIC ALIGNMENT MODEL (SAM) SELON (HENDERSON AND VENKATRAMAN 1993) ..................................................25
FIGURE 6. PROCESSUS DE TRANSFORMATION DUN MODELE METIER VERS UN MODELE TIC ................................................................28
FIGURE 7. LENTREPRISE PERUE COMME UN SYSTEME DE SYSTEMES SELON (LE MOIGNE 1984) ........................................................35
FIGURE 8. SI BOITE A OUTILS ........................................................................................................................................36
FIGURE 9. VISION SYSTEMIQUE SIMPLIFIEE DUN SI (BLOCH AND KROB 2005) ...............................................................................37
FIGURE 10. SYSTEME D'INFORMATION ET SYSTEME INFORMATIQUE .............................................................................................37
FIGURE 11. VUES DENTREPRISES (VERNADAT 1999) ..............................................................................................................42
FIGURE 12. PROCESSUS DENTREPRISE (MORLEY ET AL. 2007) ..................................................................................................44
FIGURE 13. TYPOLOGIE DES PROCESSUS................................................................................................................................45
FIGURE 14. METAMODELE DU PROCESSUS METIER SELON (MORLEY, HUGUES, LEBLANC, & HUGUES 2007) .........................................46
FIGURE 15. EXEMPLE DE PROCESSUS METIER .........................................................................................................................47
FIGURE 16. PROCESSUS METIER, PROCESSUS SI, PROCESSUS INFORMATIQUE..................................................................................47
FIGURE 17. NIVEAUX DABSTRACTION DU PROCESSUS METIER ....................................................................................................48
FIGURE 18. CYCLE DE VIE DU PROCESSUS METIER, INSPIRE DE (ZUR MUEHLEN 2004) ......................................................................50
FIGURE 19. SYSTEME REEL, MODELE, METAMODELE ................................................................................................................54
FIGURE 20. LES MODELES MDA SELON LAPPROCHE 2TUP .......................................................................................................55
FIGURE 21. MDA ADAPTE DE MODEL-DRIVEN.ORG ................................................................................................................56
FIGURE 22. DOMAINE METIER, DOMAINE SI ET MDA ..............................................................................................................57
FIGURE 23. COUCHES DE META-MODELISATION SELON MOF .....................................................................................................58
FIGURE 24. MDA, FRACTURE ENTRE DOMAINE METIER ET DOMAINE SITI .....................................................................................59
FIGURE 25. GESTION WORKFLOW ET BPM ...........................................................................................................................63
FIGURE 26. CYCLE DINGENIERIE CONTINUE DES PROCESSUS, BPM (DEBAUCHE AND MEGARD 2004) .................................................64
FIGURE 27. MDA ET BPM ...............................................................................................................................................67
FIGURE 28. DUNE ARCHITECTURE N-TIERS A UNE ARCHITECTURE N-TIERS DIRIGEE PAR LES PROCESSUS .................................................68
FIGURE 29. EVOLUTION DU MARCHE BPMS ..........................................................................................................................69
FIGURE 30. STRUCTURE BPMS ..........................................................................................................................................70
FIGURE 31. TRANSFORMATION DUN MODELE BPMN A UN MODELE BPEL...................................................................................79
FIGURE 32. DOMAINES, ACTEURS, MODELES..........................................................................................................................81
FIGURE 33. EVITER LE COUPLAGE FORT DU BPMS ..................................................................................................................84
FIGURE 34. TRANSFORMATION DE MODELES SELON IDM .........................................................................................................85
FIGURE 35. UNE BONNE ARCHITECTURE BPM (HAVEY AND HAVEY 2005) ..............................................................................86
FIGURE 36. MODELES DANALYSE ET ESPACES DES MODELES DENTREPRISES (DAPRES (TOUZI 2007) ..................................................91
FIGURE 37. ROLES ET DONNEES ..........................................................................................................................................94

xii
FIGURE 38. DE LANALYSE A LIMPLEMENTATION A LAIDE DUN PIVOT .........................................................................................95
FIGURE 39. RELATION REPRESENTATIONDE ...........................................................................................................................98
FIGURE 40. RELATION ESTCONFORMEA ...............................................................................................................................98
FIGURE 41. RELATION ENTRE M
BPA
ET MM
BPA
..................................................................................................................... 100
FIGURE 42. RELATION ENTRE M
BPI
ET MM
BPI
...................................................................................................................... 100
FIGURE 43. MODELES, METAMODELES, METAMODELE PIVOT ................................................................................................. 103
FIGURE 44. ENVIRONNEMENTS DE MODELISATION ET TRANSFORMATIONS HORIZONTALES ............................................................... 104
FIGURE 45. CLASSIFICATION DES STANDARDS LIES A BPM SELON (HOLLINGSWORTH 2004) ............................................................ 105
FIGURE 46. METAMODELE PIVOT...................................................................................................................................... 110
FIGURE 47. MODELE BPA ET MODELE BPI.......................................................................................................................... 111
FIGURE 48. EXTRAIT DU MODELE PIVOT .............................................................................................................................. 112
FIGURE 49. PROPRIETES GRAPHIQUES DE LELEMENT TASK A .............................................................................................. 112
FIGURE 50. FORMATION DUN MM
I
................................................................................................................................. 117
FIGURE 51. PLATEFORME SCALP ..................................................................................................................................... 123
FIGURE 52. INTERFACE EMF ........................................................................................................................................... 123
FIGURE 53. METAMODELE ECORE..................................................................................................................................... 124
FIGURE 54. DIAGRAMME INTALIO DESIGNER ....................................................................................................................... 125
FIGURE 55. EXTRAIT DU FICHIER DENTREE DESCRIPTION LOGIQUE ....................................................................................... 125
FIGURE 56. EXTRAIT DU FICHIER DENTREE ATTRIBUTS GRAPHIQUES ..................................................................................... 126
FIGURE 57. FICHIERS DE SORTIE POUR LE MODULE OPENERP .................................................................................................. 127
FIGURE 58. ARCHITECTURE DU FRAMEWORK LOGICIEL ........................................................................................................... 128
FIGURE 59. METAMODELE BPA ....................................................................................................................................... 130
FIGURE 60. METAMODELE BPI ........................................................................................................................................ 131
FIGURE 61. DIAGRAMME DE CLASSE DU PATTERN VISITEUR SELON (GAMMA ET AL. 1999) .............................................................. 132
FIGURE 62. PATTERN DE CONCEPTION VISITEUR, EN LANGAGE KERMETA .................................................................................... 133
FIGURE 63. PROCESSUS DE REINTEGRATION DE PARFUMS ........................................................................................................ 138
FIGURE 64. SCENARIO DE VALIDATION ............................................................................................................................... 142
FIGURE 65. DEROULEMENT DE LA PREMIERE PHASE ............................................................................................................... 143
FIGURE 66. DU DIAGRAMME DE PROCESSUS AU MODELE M
BPA
................................................................................................. 143
FIGURE 67. EXTRAIT DU FICHIER LOGIQUE ..................................................................................................................... 144
FIGURE 68. EXTRAIT DU FICHIER GRAPHIQUE .................................................................................................................. 144
FIGURE 69. EXTRAIT DE M
BPA
........................................................................................................................................... 144
FIGURE 70. DU M
BPA
AU M
PIVOT
........................................................................................................................................ 145
FIGURE 71. EXEMPLE DE M
PIVOT
........................................................................................................................................ 146
FIGURE 72. DU M
PIVOT
AU M
BPI
......................................................................................................................................... 147
FIGURE 73. EXTRAIT DE M
BPI
........................................................................................................................................... 148
FIGURE 74. DU M
BPI
AU MODULE OPENERP ....................................................................................................................... 148
FIGURE 75. DEROULEMENT DE LA SECONDE PHASE ................................................................................................................ 149
FIGURE 76. FONCTION PYTHON EXTRAITE DU FICHIER NOMMODULE.PY ...................................................................................... 149
FIGURE 77. EXEMPLE DINTERFACE POUR LE MODULE PROCESSUS DE REINTEGRATION SOUS OPENERP ......................................... 150

xiii
FIGURE 78. DU MODULE OPENERP AU LE M
BPI
.................................................................................................................... 151
FIGURE 79. EXTRAIT DU M
BPI
MODIFIE ............................................................................................................................... 151
FIGURE 80. DU M
BPI
AU M
PIVOT
......................................................................................................................................... 152
FIGURE 81. DU M
PIVOT
AU M
BPA
........................................................................................................................................ 152
FIGURE 82. DU M
BPA
AU DIAGRAMME DE PROCESSUS ............................................................................................................ 153
FIGURE 83. EXTRAIT DU FICHIER GRAPHIQUE OBTENU ....................................................................................................... 153
FIGURE 84. EXTRAIT DU DIAGRAMME DE PROCESSUS OBTENU .................................................................................................. 154
FIGURE 85. CONCEPTS-CLES DONTOCAPE POUR LA MODELISATION DE PROCEDE (YANG ET AL. 2008) ............................................. 159
FIGURE 86. DECOUPAGE DU PSE (BELAUD 2002) ET INFLUENCE POTENTIELLE DU BPA SUR LE CYCLE DE VIE DU PROCEDE ....................... 160
FIGURE 87. BPD, BFD, PFSA PARTIR DU CHEMICAL SUPPLY-CHAIN (MARQUARDT ET AL. 1999) .............................................. 161
FIGURE 88. CARDINALITES ENTRE ENTREPRISE, PROCESSUS, SOUS-PROCESSUS ET PROCEDE .............................................................. 162
FIGURE 89. APPROCHE MULTI-ECHELLE PROCESSUS-PROCEDE (SOUS FORMAT BPMN) .................................................................. 162
FIGURE 90. EQUIVALENCES SEMANTIQUES POSSIBLES ENTRE ONTOLOGIE DE DOMAINE ET REGLES METIER ? ......................................... 163
FIGURE 91. APPROCHE PIVOT POUR LA GENERATION DUN PFSA PARTIR DUN BPD ...................................................................... 164
FIGURE 92. EXTRAIT DU FICHIER M
BPA
................................................................................................................................ 194
FIGURE 93.EXTRAIT DU FICHIER M
BPI
................................................................................................................................. 195
FIGURE 94. FICHIER __INIT__.PY ..................................................................................................................................... 196
FIGURE 95. FICHIER __TERP__.PY .................................................................................................................................... 196
FIGURE 96.EXTRAIT DU FICHIER REINTEGPROCESS.PY............................................................................................................. 197
FIGURE 97. EXTRAIT DU FICHIER REINTEGPROCESS_WORKFLOW.XML ........................................................................................ 198
FIGURE 98. EXTRAIT DU FICHIER REINTEGPROCESS_VIEW.XML ................................................................................................. 199
FIGURE 99. DIAGRAMME INTALIO OBTENUE EN FIN DE SECONDE PHASE ...................................................................................... 200
FIGURE 100. DIAGRAMME INTALIO MODIFIE AU DEBUT DE LA TROISIEME PHASE ........................................................................... 201

xiv
Table des tableaux
TABLEAU 1. PRINCIPALES APPROCHES DE MODELISATION DENTREPRISE ........................................................................................39
TABLEAU 2. NOTATIONS ...................................................................................................................................................99
TABLEAU 3. EVOLUTION DE LA STANDARDISATION DU WORKFLOW ............................................................................................ 104
TABLEAU 4. RECAPITULATIFS DES STANDARDS ...................................................................................................................... 105
TABLEAU 5. FREQUENCE DOCCURRENCE DES CONSTRUCTS BPMN ........................................................................................... 108
TABLEAU 6. ELEMENTS CONSTITUANT LE METAMODELE PIVOT .................................................................................................. 109
TABLEAU 7. ATTRIBUTS COMMUNS A TOUS LES ELEMENTS ....................................................................................................... 109
TABLEAU 8. ATTRIBUT DE LELEMENT PROCESS ..................................................................................................................... 111
TABLEAU 9. ATTRIBUT DE LELEMENT BPELEMENT ................................................................................................................ 112
TABLEAU 10. ATTRIBUT DE LELEMENT EVENT ...................................................................................................................... 113
TABLEAU 11. ATTRIBUT DE LELEMENT TASK ........................................................................................................................ 113
TABLEAU 12. ATTRIBUT DE LELEMENT ACTIVITY ................................................................................................................... 113
TABLEAU 13. ATTRIBUT DE LELEMENT SUBPROCESS ............................................................................................................. 113
TABLEAU 14. ATTRIBUT DE LELEMENT LOGICAL ................................................................................................................... 113
TABLEAU 15. ATTRIBUT DE LELEMENT EDGE ....................................................................................................................... 114
TABLEAU 16. ATTRIBUT DE LELEMENT POOL ....................................................................................................................... 114
TABLEAU 17. ATTRIBUT DE LELEMENT LANE ....................................................................................................................... 114
TABLEAU 18. EXEMPLES DEQUIVALENCE SEMANTIQUE ENTRE BPMN, XPDL ET BPEL .................................................................. 116
TABLEAU 19. APPLICATIONS ET TECHNOLOGIES UTILISEES PAR LA PLATEFORME SCALP ................................................................... 134
TABLEAU 20. RECAPITULATIFS DU DEROULEMENT ET DES OBJECTIFS DU SCENARIO ......................................................................... 140
TABLEAU 21. CORRESPONDANCE SEMANTIQUE ENTRE MM
BPA
ET MM
PIVOT
................................................................................. 145
TABLEAU 22. MAPPING DE LELEMENT ACTIVITY ENTRE MM
BPA
ET MM
PIVOT
............................................................................... 146
TABLEAU 23. CORRESPONDANCE SEMANTIQUE ENTRE MM
PIVOTET
MM
BPI
................................................................................... 147
TABLEAU 24. SYNTHESE DES CONTRIBUTIONS....................................................................................................................... 171
TABLEAU 25. NOMS ET ROLES DES FICHIERS DU MODULE OPENERP .......................................................................................... 196

PREMIERE PARTIE
A. PREAMBULE
1. Introduction .. 17
2. Contexte et problmatique .. 23

16 A. PRAMBULE

RESUME
Nous prsentons dans un premier chapitre les thmes de recherches abords dans le manuscrit
ainsi que son organisation. Dans un deuxime temps cette partie prsente le contexte et la
problmatique dans lesquels sinscrivent nos travaux. Nous commenons par dcrire limportance prise
par les systmes et les technologies dinformation et du besoin dalignement sous-jacent entre le
domaine mtier dune organisation et son domaine technologique li aux systmes dinformation. Puis
nous dcrivons notre problmatique dalignement oprationnel entre les processus mtier et les
systmes et technologies dinformation dune entreprise. Enfin, cette partie se conclut par les objectifs de
recherche permettant la ralisation dun tel alignement.

1. Introduction
Nous dcrivons le cadre dans lesquels se sont raliss nos travaux. Puis nous donnons une rapide
prsentation des lments inclus dans ce manuscrit, ainsi que la manire dont ils senchanent.

C
H
A
P
I
T
R
E

1
18 A. PREAMBULE

1.1 CADRE DES TRAVAUX DE RECHERCHE
A travers ce manuscrit de thse, nous souhaitons mettre en place un cadre mthodologique
permettant le pilotage des processus mtier selon un cycle BPM en y intgrant des concepts issus de
lIDM (Ingnierie Dirige par les Modles) et de lIESI (Ingnierie de lEntreprise et des Systmes
dInformation). Cette thse sinscrit dans la ligne du groupe de travail Easy-DIM
1
du groupe de
recherche MACS
2
et du groupe de recherche I3
3
. Elle en reprend donc logiquement les thmes
principaux de recherche, savoir les problmatiques de recherche autour des modles dans lingnierie
dentreprise et de systme dinformation au cours de leur cycle de vie, de la conception aux usages. La
Figure 1, issue du livre blanc en prparation dEasy-Dim, indique et positionne ces diffrents thmes de
recherches.

Figure 1. Principaux thmes de recherches
Nous nous inscrivons tout naturellement dans les thmatiques du gnie industriel. Nous nous
intressons en particulier dterminer ladquation entre le cycle de vie du processus mtier et celui du
procd industriel au sens physico-chimique. La modlisation, au sens IDM, possde les mmes
objectifs que la modlisation au sens de lingnierie des procds ou Process Systems Engineering (PSE),
savoir lacquisition et la capitalisation des connaissances [] (et) le contrle et la supervision du
procd (ou du processus) (Truong Meyer 2009). Nous pensons quune concordance existe entre ces
cycles de vie et notamment que lingnierie des processus dentreprise peut interagir sur le cycle de vie
du procd et en permettre un meilleur pilotage. La Figure 2 rcapitule lensemble des thmatiques
abordes et notre positionnement.

1
http://www.easy-dim.org
2
http://www.univ-valenciennes.fr/GDR-MACS
3
http://www.irit.fr/GDR-I3
1. INTRODUCTION 19

Figure 2. Contexte scientifique des travaux de recherche
1.2 PRESENTATION DU MANUSCRIT
1.2.1 Dmarche propose
De manire simpliste et humoristique, la Figure 3 reprsente une caricature de la conception dun
systme.

Figure 3. Caricature de la conception dun systme
Nous constatons :
- La prolifration dacteurs, de mtier diffrent,
- Labsence de modle-rfrence, ou encore de documentation,
- Une certaine forme dincomprhension et de lacunes de communication entre acteurs.
Positionnement
de nos travaux
IDM
IESI
BPM
Technologies
logiciels et
d'information
PSE
20 A. PREAMBULE

La dmarche que nous proposons ne cherche pas rsoudre lensemble des problmes mis en
exergue par la Figure 3. Elle cherche, dans le cadre de la gestion des processus, rduire les carts
constats dans les quatre premires vignettes !
1.2.2 Typologie adopte
Pour faciliter la lecture du manuscrit, plusieurs lments sont mis en place. Dun point de vue
structuration, les parties ont t rdiges indpendamment les unes des autres. Ceci permet de les
aborder dans nimporte quel ordre, lexception des parties Prambule et Epilogue . Aussi,
chaque partie dbute par un sommaire des chapitres abords (Figure 4- a) et un rsum (Figure 4- b)
permettant de rapidement saisir le contenu trait dans la partie.

Dun point de vue contenu, chaque chapitre dispose dlments visuels afin den faciliter la lecture.
Cette reprsentation indique un terme en anglais. Nous pourrions simplement nous contenter dutiliser
le terme quivalent en franais, cependant la majorit des sujets discuts dans ce manuscrit sont
rencontrs le plus souvent dans la littrature sous leur forme anglo-saxonne.
Lutilisation de cette forme indique un terme technique, une formule mathmatique.

Et un terme indiqu de cette manire possde une dfinition dans le Glossaire situ en Annexes.
De la mme manire, un code couleur a t choisi et utilis dans les diffrents schmas :
: reprsente un lment en rapport avec le domaine mtier ;
: reprsente un lment en rapport avec le domaine SITI (Systmes dInformation et
Technologies dInformation) ;
a
b
Figure 4. Prsentation dune partie
Cette forme indique une dfinition prsente dans le corps du manuscrit
1. INTRODUCTION 21

: reprsente un lment en rapport avec lenvironnement pivot.

Px : Nom de la
x-ime proprit
Cette nomenclature indique les proprits que la plateforme
solution doit aborder ou possder.

Le document est organis de la manire suivante :
PREMIERE PARTIE : PREAMBULE
Nous prsentons dans un premier chapitre les thmes de recherches abords dans le manuscrit
ainsi que son organisation. Dans un deuxime temps cette partie prsente le contexte et la
problmatique dans lesquels sinscrivent nos travaux. Nous commenons par dcrire limportance prise
par les systmes et les technologies dinformation et du besoin dalignement entre le domaine mtier
dune organisation et son domaine technologique li aux systmes dinformation. Puis nous dcrivons
notre problmatique dalignement oprationnel entre les processus mtier et les systmes et
technologies dinformation dune entreprise. Enfin, cette partie se conclut par les objectifs de recherche
permettant la ralisation dun tel alignement.
DEUXIEME PARTIE : CADRE METHODOLOGIQUE
Nous cherchons dfinir les notions et concepts qui sont utiliss au sein de nos travaux. La
premire partie de ce chapitre sintresse la dfinition de lentreprise et sa modlisation. Un tat de
lart des diffrentes mthodes de modlisation nous permet de justifier notre approche oriente
processus. Puis nous examinons la notion de processus proprement dite. Nous prsentons galement
les disciplines et mthodes permettant la manipulation de modles de processus.
TROISIEME PARTIE : DEFINITION DE LAPPROCHE
Nous mettons en avant les dysfonctionnements de lingnierie des processus mtier lors de son
application. Aprs un court exemple utilisant les standards les plus rpandus du BPM, nous discutons
des limites dune dmarche BPM. De ces limites, nous exposons les solutions quapporte notre approche
pivot. Les chapitres suivants dfinissent le champ dapplication de notre approche ainsi que ses
caractristiques. Nous insistons en particulier sur les liens existants entre modles et mtamodles, ainsi
que sur la formation et la constitution du mtamodle pivot.
QUATRIEME PARTIE : MISE EN UVRE
Les diffrents lments constituant la plateforme solution exprimentant notre approche sont
dvelopps. Puis un cas concret dutilisation de notre approche sera prsent. Un processus rel et
utilis en industrie sera manipul depuis sa modlisation sa transformation en module fonctionnel pour
un logiciel de type ERP. Nous prsentons aussi nos travaux de recherche relatifs la possible
adquation entre lingnierie des processus et lingnierie des procds. Nous pensons quune telle
adquation est possible travers lutilisation de notre approche pivot, et nous cherchons le dmontrer.
22 A. PREAMBULE

CINQUIEME PARTIE : EPILOGUE
Cette dernire partie contient une conclusion gnrale portant sur lensemble du manuscrit. Cette
partie contient galement les annexes et la bibliographie.

2. Contexte et problmatique
Ce chapitre expose le contexte scientifique dans lequel sinscrivent nos travaux. En premier lieu,
nous cherchons caractriser et dfinir la notion dalignement, en particulier lalignement entre
processus dentreprise et systmes dinformation. Notre objectif, travers ce chapitre, est didentifier
limportance graduelle quont pris les systmes dinformation au sein dune organisation.
Puis nous dveloppons la problmatique aborde et les questions qui y sont rattaches. Pour cela,
nous nous intressons lalignement entre modles de processus mtier et modles dimplmentation
destins aux systmes dinformation. De fait, nous cherchons dfinir prcisment la notion dalignement
entre ces deux entits. Puis nous dmontrons la difficult mettre en place un tel alignement et de lcart
entre le domaine mtier et le domaine technologies des systmes dinformation qui en dcoule.

C
H
A
P
I
T
R
E

2
24 A. PREAMBULE

2.1 CONTEXTE
Afin de demeurer comptitives et dtre en mesure de rpondre aux challenges du march actuel,
les organisations modernes se doivent dtre agiles, autrement dit, que ce soit dun point de vue inter ou
intra-organisationnel, les diffrents systmes constituant lorganisation doivent pouvoir intervenir
rapidement sur la chane de valeur. Une entreprise doit galement tre capable dinteragir de manire
optimale avec lensemble des acteurs la constituant, quils appartiennent au domaine mtier de
lentreprise ou au domaine des Systmes dInformation (SI). Dans la suite du manuscrit, nous constatons
la forte dpendance existante entre lentreprise et son systme dinformation. Puis nous montrons
travers nos travaux limportance de lalignement de lentreprise avec ses systmes dinformation et
exposons lintrt de percevoir lensemble des lments composants une entreprise comme un tout
cohrent.
2.1.1 Naissance et importance des stratgies SITI et mtier
Depuis 1960, les Technologies de lInformation (TI) et les systmes d'information se sont
caractriss par un dveloppement rapide, et ont merg dans le domaine mtier dune organisation
jusqu en devenir des lments essentiels. La majorit des organisations, que ce soit dans les secteurs
de l'industrie, des affaires et du commerce, du gouvernement, ou encore de la sant sont
fondamentalement tributaires de leurs systmes et des technologies de l'information (dans la suite du
manuscrit, nous utiliserons lacronyme SITI pour les dsigner). Pour que les organisations demeurent
comptitives dans un environnement socio-conomique dynamique, elles doivent dterminer et
comprendre comment grer efficacement et de faon stratgique le domaine SITI. Possder un systme
d'information efficace et efficient supportant les stratgies mtier et les processus qui y sont rattachs est
rapidement devenu un facteur cl de succs (Henderson and Venkatraman 1999). Ceci permet un
rendement organisationnel efficace qui apporte une contribution la cration de valeur, et ce dune
manire reconnue.
2.1.2 Besoin dun alignement entre stratgie mtier et stratgie SITI
Cest pourquoi le besoin daligner le SI la stratgie dentreprise est devenu en quelques annes
la priorit absolue des directeurs des systmes dinformation (Luftman and Maclean 2004). De cet
alignement rsulte un accroissement de la performance dune organisation. A linverse, si cet alignement
nest pas ralis correctement, les processus dentreprises nutiliseront pas les ressources
technologiques mises en uvre de manire optimale. En consquence, une organisation doit tre en
mesure de dfinir des processus dentreprise rpondant aux exigences mtier de ses dcideurs, ainsi
que de construire des SI performants. Ces systmes sont jugs performants sils prennent correctement
en charge les processus, permettant le bon fonctionnement et une augmentation de la performance de
lorganisation.
2. CONTEXTE ET PROBLEMATIQUE 25

Les SITI sont ainsi devenus une partie intgrante de la plupart des formes de structure public et
socio-conomique (entreprise commerciale ou individuelle, association, collectivits, administration,)
4
.
Les SI dpassent le traditionnel rle de back-office qui leur tait attribus et acquirent une valeur
stratgique prendre en considration au sein de la stratgie de lentreprise. Un alignement explicite
entre domaine mtier et SITI devient ncessaire afin de ragir efficacement et avec agilit face aux
vnements exognes ou endognes de lentreprise. Ces vnements peuvent tre une modification des
besoins clients ou des objectifs de lorganisation entranant des changements au niveau des processus
dentreprise et donc des SI. Ainsi le type dinteractions existant entre mtier et SITI ne se restreint pas au
seul niveau stratgique, il couvre galement le niveau oprationnel (entre processus dentreprise et SI)
comme nous allons le voir.
2.1.3 Alignement stratgique, alignement oprationnel
Un alignement stratgique amliore la performance organisationnelle travers divers mcanismes
comme les processus de pilotage, les ressources humaines et les capacits technologiques, o ces
capacits peuvent tre interprtes essentiellement comme la capacit dployer des ressources (Amit
and Schoemaker 1993). Ce concept d'alignement a t prsent par (Henderson & Venkatraman 1993)
qui ont propos le modle d'alignement stratgique Strategic Alignment Model, SAM reprsent Figure 5.

Le SAM fait une distinction entre un domaine externe et un domaine interne. Le domaine externe
porte sur la formulation des stratgies refltant l'environnement dans lequel sinscrit lentreprise. Le
domaine interne se proccupe de linfrastructure SITI et des processus dentreprise. Lajustement
stratgique dcrit la relation verticale existant entre un domaine externe et le domaine interne qui lui est
associ. Lintgration fonctionnelle reprsente la relation horizontale existant entre deux domaines. Cette
dernire relation peut galement tre perue comme un alignement oprationnel (Wagner et al. 2006).

4
Nous utiliserons maintenant le terme entreprise pour dsigner ces diffrents types de structures.
Stratgie dentreprise
Infrastructure et
processus dentreprise
Infrastructure et
processus techniques
Stratgie Techniques
dInformation
Intgration fonctionnelle
Ajustement
stratgique
Externe
Interne
Figure 5. Strategic Alignment Model (SAM) selon (Henderson and Venkatraman
1993)
26 A. PREAMBULE

De nombreuses contributions soulvent limportance dun alignement stratgique SITI-mtier
(Broadbent and Weill 1993), (Luftman and Brier 1999), (Avila Cifuentes 2009), (Cuenca et al. 2010).
Lalignement stratgique SITI-mtier peut tre conceptualis laide du modle SAM sous la forme de
deux actions (ou briques ) : un ajustement plus un alignement. Cet enchanement est dfini comme
tant une squence dalignement.
A loppos, les implications directes pour l'entreprise quant la relation entre les SI et les units
mtier sont beaucoup moins reprsentes dans la littrature (Gordon and Gordon 2000). Ainsi, peu
d'attention a t accorde aux relations pouvant exister entre les SI (infrastructures et processus
techniques) et les units mtier (infrastructures et processus dentreprise) qui utilisent ces systmes
d'information.
2.1.4 Emergence dun nouveau domaine de lingnierie des SI
L'alignement entre la stratgie d'entreprise et les choix de dploiement des SITI sont devenus un
point important de proccupation pour les entreprises (Silvius 2007), (Ward and Peppard 2002). Ceci est
particulirement le cas lorsque les SITI deviennent une partie essentielle de l'entreprise et sont utiliss
pour exploiter des comptences mtier spcifiques, mis contribution lors de fusions entre entreprises,
lors de restructuration (Earl 1992), (Chan et al. 1997), (Luftman & Maclean 2004) insistent sur
limportance prise par lalignement entre la stratgie de lentreprise et les SITI, qui en 20 ans est devenu
un enjeu majeur de gestion. Si lintrt de raliser un tel alignement est reconnu, sa mise en uvre reste
trop souvent limite. Il nest pas rare que les acteurs de l'organisation ne savent pas en quoi consiste cet
alignement, de mme quil existe une absence de communication entre domaine mtier et domaine SITI.
De ce fait, les entreprises et les experts SITI sont constamment la recherche de meilleures
pratiques de gestion les aidants aligner leurs stratgies mtier avec les SITI. Nous avons vu que de
nombreux travaux de recherche sintressent et tudient cet alignement. Nous pouvons galement
signaler que plusieurs ateliers lui ont t consacrs (BPMDS, 2004
5
, REBNITA, 2005
6
, MOSIM, 2010
7
). A
travers ces diffrents articles et/ou prsentations, les auteurs mettent en avant des mthodes et des
outils propres lalignement, par exemple pour construire un systme et des processus dentreprise
aligns, ou pour valuer lvolution de la relation dalignement au cours du temps (Avila Cifuentes 2009).
Tout ceci participe lmergence dun domaine de lingnierie des SI : celui de lingnierie de
lalignement. (Etien 2006) observe que l lingnierie de lalignement peut tre considrer comme un sous-
domaine de lingnierie des systmes dinformation, au mme titre que lingnierie des mthodes ou de
lingnierie des exigences. Lingnierie de lalignement devrait ainsi tre considre comme une
discipline part entire, de part limportance que revt lalignement pour les chercheurs, les entreprises
et leurs acteurs.

5
Fifth Workshop on Business Process Modeling, Development, and Support, CAiSE 2004
6
1st International Workshop on Requirements Engineering for Business Need and IT Alignment, 13th IEEE International
Conference on Requirements Engineering, 2005.
7
8me ENIM IFAC Confrence Internationale de Modlisation et Simulation, 2010

Ce manuscrit contribue la littrature en apportant des solutions pour un meilleur alignement
oprationnel.
2.2 PROBLEMATIQUE
Pouvoir saisir de nouvelles opportunits ncessite de la flexibilit au niveau du mtier dune
organisation. Cette flexibilit se traduit par lutilisation de processus dentreprise supports par les SI.
Cette flexibilit de gestion permet dobtenir lagilit dentreprise souhaite. Lagilit des SI est prsente
en dtail par (Boucher 2007). Cependant nous observons une discontinuit franche entre domaine mtier
et domaine SITI. Ainsi, au lieu de permettre et daccompagner le changement des processus, les SI
peuvent brider ou ralentir la mise en place de telles volutions. Notre prsent travail est motiv par la
ralisation dun alignement entre domaine mtier et domaine SITI selon une dmarche oriente
processus permettant de rsoudre ces diffrents points. Nanmoins, ils subsistent plusieurs difficults
inhrentes lutilisation dune telle approche.
REMARQUE : AGILITE OU FLEXIBILITE
Les concepts dagilit et de flexibilit peuvent paratre trs proches en thorie. Cependant, ces deux termes
prsentent des diffrences notables. La flexibilit est semblable la notion de ractivit industrielle, savoir la
capacit dune entreprise rpondre rapidement aux besoins de ses clients par une attribution diffrente de ses
ressources. Lagilit dfinit la capacit dune entreprise sadapter rapidement son environnement, permettant de
procder des changements harmonieux et continus de lorganisation.

2.2.1 Alignement oprationnel, intgration fonctionnelle, cohrence,
(Avison et al. 2004) estime que la notion dalignement demeure mal dfinie, tant entre stratgies
dentreprise et stratgies des SITI quau niveau oprationnel, entre SI et processus dentreprise. Cette
absence formelle de dfinition nous amne nous poser des questions sur ses caractristiques et ses
objectifs.
A travers la solution propose, nous considrons que lalignement oprationnel permet de rduire
lcart reconnu entre domaine mtier et SITI. Ds lors, lalignement est-il considr comme un tat
atteindre ou un processus mettre en uvre ? De mme, est-il erron dassocier la dfinition de
lalignement oprationnel celle de lintgration fonctionnelle ?
2.2.2 Cycles de vie dapplications et de technologies asynchrones
Les applications et technologies des domaines mtier et SITI voluent diffremment au cours du
temps.
Les besoins mtier dune organisation sillustrent par leur constante volution. Leurs volutions
sont dues un march changeant, aux acquisitions et fusions entre entreprises, lapplication de
nouvelles stratgies et aux priorits dictes par les investisseurs. Les ncessits mtier lies au
changement forment un processus totalement imprvisible. Les produits associs aux technologies de
28 A. PREAMBULE

linformation (par exemple les services Web ou J2EE) sont mis jour une deux fois par an. Nous
pouvons observer des changements de tendances majeures tous les deux cinq ans.
Ainsi, les cycles de vie sont diffrents pour les besoins mtier, les SITI, les projets et les produits
qui y sont associs. Cette dsynchronisation cre une discontinuit entre le processus souhait (as-wish,
processus dentreprise) et le processus implment par le systme dinformation (as-is, processus
technique) les mettant en uvre.
2.2.3 De la difficult maintenir lalignement
Maintenir un alignement oprationnel revient conserver une cohrence smantique et structurelle
entre modles htrognes et dabstraction/granularit diffrentes. Un non-alignement se cre entre ces
modles htrognes lors de leurs manipulations : il s'agit de lcart mtier-SITI tel que dcrit dans la
littrature. Pour se rendre compte de la difficult raliser ce maintien, considrons le processus de
transformation depuis un modle mtier vers un modle SITI, issus de leurs domaines respectifs. Ce
processus est reprsent Figure 6 (Stein et al. 2008).

Le domaine mtier produit des modles de processus non-formels et interprtables
essentiellement par lhomme rendant la phase dimplmentation sexcutant au niveau SITI plus
complexe. Une premire transformation depuis un modle mtier vers un modle SITI est ncessaire. Il
convient de garder lesprit que ces modles sont amens tre modifis, les processus reprsents et
les technologies de linformation utilises pouvant voluer comme nous lavons indiqu prcdemment.
Modle
Papier
Modle
mtier
Modle
mtier
Modle SITI
raffin
Modle SITI
Modle
SITI
Modle SITI
raffin
Synchronisation
Niveau
dabstraction
Temps
Transformation
Evolution
Modification
manuelle
Evolution
Transformation Transformation
Figure 6. Processus de transformation dun modle mtier vers un modle TIC

Des efforts de synchronisation, de mises jour et de cohrence entre modles savrent alors
ncessaires pour garantir leur alignement.
2.3 OBJECTIFS DE RECHERCHE
Afin damliorer les stratgies dalignement actuelles, nos travaux suggrent une approche
gnrique pour la modlisation et limplmentation des processus et de raliser une plateforme
supportant une telle approche.
2.3.1 Contributions
Nous proposons une mthode permettant le pilotage des processus mtier, de leur modlisation
leur implmentation au sein dun SI. A l'aide de concepts issus de l'ingnierie d'Entreprise et des
Systmes d'Informations dirigs par les modles et des SITI, nous dfinissons une dmarche gnrique
assurant une cohrence intermodle. Son rle est de conserver et de fournir toutes les informations lies
la structure et la smantique des modles.
En permettant la restitution intgrale d'un modle transform au sens de l'ingnierie inverse, notre
plateforme permet une synchronisation entre modle d'analyse et modle d'implmentation issus
respectivement du domaine mtier et du domaine SITI. La cohrence intermodle et la synchronisation
obtenue sont les conditions ncessaires et suffisantes permettant un alignement oprationnel entre les
domaines considrs.
Nous envisageons galement l'adquation possible entre l'ingnierie des procds et lingnierie
des processus dentreprise travers un point de vue multi-chelle et justifie par notre cadre
mthodologique.
2.3.2 Rsultats principaux
Suite nos travaux, nous proposons les principaux rsultats suivants qui seront dtaills tout au
long de ce manuscrit :
- Une analyse bibliographique du domaine ;
- Une approche Business Process Management-BPM reposant sur un lment-pivot,
- Une plateforme logicielle nomme Solution pour la Cohrence et lAgilit des Processus
(SCALP),
- Une tude de cas,
- Une ouverture vers le Process Systems Engineering- PSE.

DEUXIEME PARTIE
B. CADRE METHODOLOGIQUE
3. De lentreprise au processus 33
4. Notions autour du terme processus 43
5. Ingnierie et Architecture Diriges par les Modles 53
6. Ingnierie des processus mtier 61

32 B. CADRE METHODOLOGIQUE

RESUME
Nous cherchons dfinir les notions et les concepts qui sont utiliss au sein de nos travaux. La
premire partie de ce chapitre sintresse la dfinition de lentreprise et sa modlisation. Un tat de
lart des diffrentes mthodes de modlisation et autres lments bibliographiques nous permettent de
justifier notre approche oriente processus. Puis nous examinons la notion de processus proprement
dite. Nous prsentons galement les disciplines et mthodes permettant la manipulation de modles de
processus.

3. De lentreprise au processus
Dans ce chapitre, nous dcrivons le cheminement permettant de passer du niveau dabstraction de
lentreprise celui de processus. Nous dfinissons les diffrents concepts ponctuant cette approche. Les
diffrents cadres de modlisation utiliss sont alors dcrits avec notamment les vues et les
caractristiques quils considrent.

C
H
A
P
I
T
R
E

3

3.1 ENTREPRISE
REMARQUE : ENTREPRISE ET SYNONYMES
Dans lensemble du manuscrit, le terme entreprise est considr comme synonyme des termes organisation, socit
ou encore compagnie.

3.1.1 Dfinition
Une entreprise est, selon (Izza 2006), le sige dactivits les plus diverses visant crer de la
valeur et dans laquelle linformation est considre comme une essence et une ressource vitale pour son
fonctionnement . Dans le reste du manuscrit, nous suggrons la dfinition suivante dune entreprise :

Les buts et objectifs sont atteints grce lorchestration dactivits diverses ralises laide
dacteurs et des ressources de lentreprise.
Une entreprise peut galement adopter un comportement mergent, cest--dire quil est a priori
imprdictible. Nous la qualifierons comme tant un systme sociotechnique complexe (Aloui 2007).
Dans le rapport de laction spcifique PRODLOG (AS n35 PRODLOG)du GDR MACS (LAAS-
CNRS 2003), ces activits sont mises en uvre par des ressources sociotechniques dans le cadre
d'une finalit identifie. Ces activits peuvent s'excuter aussi bien au sein d'un projet, d'une entreprise
traditionnelle, ou d'un rseau de socits . La ralisation de ces activits collectives dans un domaine
particulier, car impliquant diffrents acteurs partageant un but commun est la dfinition mme du mtier
dune entreprise selon (Martin et al. 2004). Il convient de noter quune entreprise peut galement tre
perue comme une collection de mtier . Nous proposons et retiendrons la dfinition suivante dun
mtier dentreprise :

Une entreprise est un systme socio-technique motiv par un ou plusieurs
buts et objectifs. Elle possde une complexit apparente la fois
structurelle et organisationnelle. Ce systme est ouvert, car il possde des
relations avec des entits extrieures et est dynamique, sa structure et son
organisation ntant pas figes dans le temps.
Le mtier dune entreprise reprsente un ensemble dactivits dun
domaine donn ncessitant des comptences et savoir-faire des acteurs de
lentreprise.
3. DE LENTREPRISE AU PROCESSUS 35

A travers ces diffrentes dfinitions, nous voyons quune entreprise est un systme complexe de
systmes. Afin danalyser les proprits dune entreprise, nous devons dfinir ses sous-systmes
caractristiques.
3.1.2 Entreprise, un systme de systmes
Les proprits que nous dsirons mettre en avant sont celles lies la reprsentation et la
modlisation de lentreprise en tant que systme de systmes. Nous ne nous intressons pas aux
aspects lis au march conomique, au dveloppement de lentreprise, aux considrations sociales et
socitales Nous pouvons distinguer trois aspects caractrisant le systme entreprise. Laspect
fonctionnel de lentreprise reprsente lensemble des tches existantes dune entreprise (les applications
dentreprises). Laspect comportemental dfinit les diffrents ordres disponibles dexcution des tches
dune entreprise, que nous nommons processus organisationnels ou processus mtier. Laspect
dynamique du comportement prend en compte les ressources et le temps de lentreprise.
Selon (Le Moigne 1984), nous avons trois sous-systmes caractrisant le systme sociotechnique
complexe quest lentreprise. Tout dabord, le systme oprant, qui ragit aux vnements quotidiens, qui
viennent de lenvironnement, selon des rgles dfinies. Il est charg de transformer des ressources ou
flux primaires (flux financiers, flux de personnel, flux de matire, flux dinformation). Ensuite, le systme
de pilotage, qui permet dengager le processus de dcision tout en dfinissant au pralable les objectifs,
les critres dvaluation et les rgles de gestion. Enfin, le Systme dInformation (SI), qui relie les deux
systmes prcdents tout en jouant un rle de coupleur (Figure 7). Il correspond la partie charge
de la collecte, du traitement, du stockage et la diffusion des informations. Il peut tre peru comme une
reprsentation du systme oprant et/ou du systme de pilotage.
Dans les paragraphes suivants, nous nous attachons dfinir la notion de ce systme
dinformation, cur du systme de systmes que reprsente lentreprise.

Figure 7. Lentreprise perue comme un systme de systmes selon
(Le Moigne 1984)

3.2 SYSTEME DINFORMATION
Le Systme dInformation (SI) est devenu le centre du fonctionnement de tout type dentreprise.
Son efficacit est un lment-cl de la performance de ces entreprises. Il est mme considr comme
tant lobjectif global recherch de la modlisation dentreprise (Ferchichi 2008).
Plusieurs dfinitions sur le systme dinformation existent. La dfinition d(Alter 1999) dfinit un
systme dinformation comme un systme de travail dont les fonctions internes sont limites traiter
linformation, en excutant six types doprations : saisir, transmettre, stocker, retrouver, manipuler,
afficher linformation. Un systme dinformation produit de linformation, assiste ou automatise le travail
excut par dautres systmes de travail. Selon cette dfinition, nous pourrions presque borner
lutilisation dun SI celui dun systme informatique, ce qui reste trs rducteur pour le SI ! Nous
retrouvons cette notion dun SI trs informatis, transformant des donnes en informations puis les
redistribuant, nayant quune faible partie dcisionnelle dans la dfinition de (Le Moigne 1984) vue dans le
paragraphe prcdent.
Au dbut des annes 2000, la dfinition du SI se fait plus globale. (Reix 2004) ne fait pas de
distinction entre les trois sous-systmes dune entreprise en considrant le SI (Figure 8) comme un
ensemble organis de ressources : matriel, logiciel, personnel, donnes, procdures permettant
dacqurir, traiter, stocker, communiquer des informations (sous forme de donnes, textes, images, sons,
etc.) dans lorganisation.

Il est caractris par (Laleau 2002) :
- Lutilisation de plusieurs donnes,
- Des relations complexes entre les structures de donnes,
- Des oprations impliquant plusieurs structures de donnes, un important volume de
donnes et prservant nanmoins lintgrit des donnes modifies,
- Des utilisateurs htrognes pouvant agir en concurrence,
Systme
dInformation
Figure 8. SI bote outils

- Une communication adapte des requtes des utilisateurs et une gestion des messages
derreur en cas dappel invalide des oprations.
Il faut attendre 2005 pour obtenir des dfinitions du SI o le souci dorganisation apparat. Ainsi
(Bloch & Krob 2005) considre non seulement le systme informatique mais galement lorganisation de
lentreprise comme lments du systme dinformation (Figure 9). La notion de SI est en effet troitement
lie celle dorganisation.

Nous remarquons aussi que (Morley, Hugues, Leblanc, & Hugues 2007) distingue clairement le SI
du systme informatique comme le montre la Figure 10. En considrant le SI sous la gouvernance du
systme de pilotage, nous retrouvons lentreprise systme de systmes telle que dfinie par
(Lemoigne 1984), o le SI supportant la gestion de lentreprise est support par les ressources
informatiques daide la dcision.

Stratgie
Systme
Informatique
Organisation de
lEntreprise
Management
Systme dInformation
Figure 9. Vision systmique simplifie dun SI (Bloch and Krob 2005)
Systme dInformation
Acteurs
Processus Informations
Systme Informatique
Logiciels
Matriels Applicatifs
Sappuie sur
Permet
Figure 10. Systme d'information et systme informatique

Dans la suite du manuscrit, nous considrons le SI selon la dfinition de (Morley, Hugues, Leblanc,
& Hugues 2007) :

Une fois ces diffrents systmes reconnus, il faut modliser ce systme complexe quest
lentreprise. Cette reprsentation se fait laide dun ensemble de modles. Nous prsentons
succinctement les mthodes supportant cette modlisation dentreprise.
3.3 MODELISATION DENTREPRISE
La modlisation dentreprise a pour objet la construction du modle de tout ou partie de
lentreprise. Lentreprise est alors vue comme un systme et sa modlisation doit en expliquer la
structure, lorganisation et le fonctionnement (Pourcel and Gourc 2005). Le modle ralis doit fournir
une reprsentation de larchitecture de lentreprise facilitant sa comprhension. Nous considrons quil
permet danalyser le comportement et de situer le fonctionnement du systme en cohrence avec la
stratgie de lentreprise. La modlisation dentreprise est galement perue comme un art
dexternaliser le savoir-faire de lentreprise (Touzi et al. 2008) , la rendant de ce fait comme un prrequis
pour une dmarche dintgration dentreprise. La conception dun systme sociotechnique complexe
(numrique, analogique ou mixte) se caractrise par une forte augmentation de sa complexit alors que
les cycles de dveloppement sont de plus en plus rduits. Le recours des formalismes et des outils
devient plus que ncessaire. Les mthodes de modlisation diffrent selon le point de vue quelles ciblent
(oprant/information/dcision) ou selon leurs objectifs (audit/ analyse/ conception).
Idalement, une Mthode de Modlisation dEntreprise (MME) doit pouvoir dcrire les aspects
comportementaux (notamment la gestion des vnements), fonctionnels et dynamiques, dcrits au dbut
de la section 3.1.2, ainsi que la formalisation des savoirs-faire. Plusieurs dfinitions dune MME existent,
(Vernadat and Hamaidi 1998) considre les MME de la manire suivante :
Une MME fournit la description de lorganisation des processus dun systme soit dans le but de
les simuler pour comparer divers scnarios, soit dans le but de les analyser et de les restructurer pour
amliorer la performance systme
Une MME doit galement tre en mesure de reprsenter la structure de pilotage ou des aspects
lis la gouvernance de lentreprise. Toutes les mthodes de modlisation dentreprise manipulent les
quatre composants de base suivant :
- Objets (produit ou objet technique, information ou objet symbolique,) ;
- Ressources (humaines, techniques, naturelles) ;
- Activits et processus ;
- Diffrents aspects dynamiques, conomiques humains et sociaux.
Un systme dinformation est la partie relle constitue dinformations
organises et dacteurs qui agissent sur ces informations ou partir de ces
informations, selon des processus visant une finalit de gestion et utilisant
des technologies de linformation.

Nous pouvons diffrencier ces mthodes selon le type de mthodes utilises (Aloui 2007), (Darras
2004). Nous pouvons en distinguer deux en particulier.
Considrons en premier lieu les mthodologies se reposant sur une architecture de rfrence.
Cette architecture est forme par les modles dentreprises et les mthodes de conception quils sous-
tendent. Citons par exemple CIMOSA (AMICE 1993), ARIS (Scheer 2002), GERAM (IFAC-IFIP Task
Force 1997).
Puis nous avons des mthodes appliquant elles-mmes des mthodes dites oprationnelles. Nous
pouvons citer SADT, mthode gnrale o un systme complexe est peru puis dcompos en plusieurs
systmes simples. La mthode GRAI (Roboam 1993) est une mthode oriente systme de dcision.
Nous avons galement des mthodes ddies aux SI comme MERISE (Tardieu et al. 2002), oriente
processus et SI comme OLYMPIOS (Throude et al. 2001). Nous avons enfin des mthodes
oprationnelles reposant sur les langages de modlisation dentreprise, comme UML (OMG 2007a) ou
BPMN (OMG 2008).
Les approches utilises permettent galement de diffrencier les types de mthodes selon trois
approches. (1) Lapproche fonctionnelle est base sur le principe de dcomposition descendante ou
approche top-down. Elle est modulaire et structure. Les mthodes sy rapportant reprsentent le plus
souvent des diagrammes de flux de donnes centrs sur les fonctions du systme. (2) Lapproche
systmique se base sur linteraction des systmes, en particulier lanalyse des flux, la sparation des
donnes et traitements et considre les niveaux organisationnels et conceptuels. (3) Lapproche oriente
objet est plus oriente conception des systmes dinformation quanalyse de ces derniers.
A ces trois approches, nous pouvons rajouter lapproche oriente processus permettant de
reprsenter les modles dentreprise centrs autour de ses processus (Bouchiba and Cherkaoui 2007)
(Tableau 1). Les processus dfinissent les diffrentes actions ralises au sein dune entreprise, depuis
la prise de dcision jusqu la gestion de ressources. Ils sont troitement lis au SI de lentreprise, dont le
rle devient alors critique lors de son adaptation son environnement. (Sadiq et al. 2004) constate ainsi
quune entreprise qui ne sengage pas dans une approche oriente processus est dcrite par de
nombreux diteurs comme tant une organisation qui sera dans limpossibilit de rpondre rapidement
aux conditions changeantes du march et de son environnement.
Tableau 1. Principales approches de modlisation dentreprise
Approches Structure Systmique Oriente objet Oriente Processus
Mthodes, langages
et outils
SADT-IDEF0
IDEF2, 3
CIMOSA, MERISE, GRAI, GIM ; PERA,
GERAM ; UEML
UML

ARIS
SCOR
Ces approches sont accompagnes de cadres de modlisation afin den faciliter la ralisation.
Nous nallons pas dcrire de faon exhaustive ces diffrents cadres mais plutt dcrire brivement leurs
principaux concepts.
3.4 CADRE DE MODELISATION DENTREPRISE
Plusieurs dfinitions sur les cadres de modlisation, ou frameworks, existent (Martin, Robertson, &
Springer 2004). Nous proposons la dfinition suivante :

Il peut exister une confusion entre larchitecture dune entreprise et son cadre de modlisation. Le
premier terme dsigne le fonctionnement et lorganisation de lentreprise alors que le second se
concentre en particulier sur la dfinition et la mise en uvre du SI et des processus mtier de
lentreprise. Nanmoins ces deux termes demeurent indissociables lun de lautre. Comme nous lavons
prsent prcdemment, afin de capitaliser les savoirs et daugmenter les performances gnrales dune
entreprise, nous procdons un alignement du SI sur la stratgie de lentreprise, et ce, laide de
modles. La modlisation peut tre ralise selon une mise en perspective du modle par les utilisateurs,
reposant essentiellement sur le cadre propos par Zachman en 1987. Cette approche est la plus
frquemment utilise dans des configurations commerciales et gouvernementales. Une seconde
approche peut tre lutilisation de cycle de vie comme thme de modlisation, reposant sur les trois
normes ISO suivantes : 15704 : 2000 ; 19439 : 2003 et 15288 : 2002. Une telle approche reste populaire
en production et automatisation industrielles et en ingnierie des systmes.
Un cadre de modlisation dentreprise dcrit le plus souvent les trois dimensions suivantes : le
cycle de vie, la structure et le comportement du modle et son degr de particularisation.
3.4.1 Cycle de vie
Le cycle de vie dun modle reprsente ses diffrents niveaux de drivation. Il dcrit le modle
depuis lnonc des prescriptions pour arriver un modle traitable par informatique (Pourcel &
Gourc 2005). La dimension exprime les points de vue principaux du mtier de lentreprise (Darras 2004)
travers les trois tapes suivantes :
- Expression des besoins. Ce niveau prend en considration le cahier des charges :
lidentification, la dfinition et la ralisation des spcifications et exigences du client.
- Spcification de conception. Il sagit danalyser et de spcifier des solutions en adquation
avec les besoins exprims dans le cahier des charges. Cette tape nest pas anodine, il faut
effectivement dfinir ces besoins en fonction des possibilits du systme dinformation et du
march (o nous recherchons des choix techniques abordables en termes de cots, performance
et dlais).
- Description de limplantation. Ici, nous fournissons une description de limplantation retenue.
Cette implantation du systme doit se faire en considrant les autres systmes existant en
prvision dune intgration ou connexion entre eux.
A laide de ces diffrentes tapes, le cycle de vie, bien que non-temporel stricto sensu, tend
servir dordonnancement pour les oprations de lentreprise (Martin, Robertson, & Springer 2004).
Un cadre de modlisation dentreprise propose une approche, incluant un
ensemble de composants - modles et dfinitions - formant un squelette
adaptable et/ou modifiable au domaine dapplication de lentreprise et ce
dans le but de dvelopper et documenter les descriptions darchitecture.

3.4.2 Structure et comportement
Cette dimension regroupe les diffrentes vues de modlisation de lentreprise. La reprsentation
dune entreprise travers un seul point de vue serait incomprhensible. La complexit dune entreprise
peut tre reprsente selon diffrents points de vue. Ces diffrentes dclinaisons permettent une
meilleure comprhension de lentreprise en dfinissant plusieurs catgories dacteurs. Dans la suite du
manuscrit, nous utiliserons la notion de vues dentreprise afin damliorer la lecture. Selon (IEEE
2000) :

Selon la norme (ISO TC 184/SC 5 2000), nous pouvons en dnombrer quatre. La vue fonctionnelle
dcrit les processus et leurs structures. Nous identifions les noms, buts et actions des processus. La vue
informationnelle forme le data-flow. Cette vue indique quels sont les documents et donnes utiliss
chaque tape dun processus. Elle dcrit les objets du systme, leurs relations et leurs diffrents tats
possibles. La vue organisationnelle dfinit les agents responsables et aptes excuter le processus.
Enfin, la vue des ressources, ou vue oprationnelle, spcifie les outils ou les systmes permettant la
ralisation du processus en dcrivant les moyens humains et matriels ncessaires, ainsi que le mode de
gestion de ces ressources.
Chacune de ces vues manipulent des concepts diffrents et peuvent tre exprimes travers un
formalisme diffrent, cependant il faut veiller garder une cohrence globale. Elles ne possdent pas
non plus la mme importance lors dune dmarche de modlisation dentreprise. (Vernadat 1999) et
(Touzi 2007) situent la vue fonctionnelle au centre des autres vues dentreprise comme le montre la
Figure 11.
(Jablonski 2009) distingue la vue comportementale de la vue fonctionnelle. La vue
comportementale dfinit les dpendances entre processus et donc lordre dans lequel ces processus sont
excuts. Ainsi il dtermine le control-flowentre processus.
3.4.3 Degr de particularisation
Cette dimension permet didentifier lensemble des modles possibles spars selon leur niveau
de gnricit du modle.
Cette dimension comporte ainsi trois niveaux :
- Niveau gnrique : ce modle dfinit les primitives de base du langage de modlisation ;
- Niveau partiel : ce modle dcrit des structures prdfinies et rutilisables pour un domaine
dapplication ;
- Niveau particulier : ce modle dcrit les spcificits du systme tudi.
Une vue est une reprsentation de tout un systme selon la perspective
dun ensemble dintrts lis.

3.5 CONCLUSION
Afin den embrasser toute la complexit, lentreprise est considre comme un systme de
systmes. Le systme dinformation se dmarque du systme de pilotage et du systme oprant par son
importance. Situ au cur de lentreprise, le SI permet de mettre en uvre les diffrentes stratgies et
objectifs de lentreprise.
Une entreprise peut tre modlise par plusieurs approches et selon plusieurs vues. La vue
fonctionnelle se distingue des autres vues en se positionnant au centre de ces dernires, comme
lindique la Figure 11. Nous pouvons galement constater que llment processus est un lment central
de cette vue fonctionnelle. Au cours de ce manuscrit, lapproche oriente processus peut simposer
comme lapproche fondamentale garantissant lagilit requise par lentreprise. Le chapitre suivant discute
des diffrentes notions attenantes au terme processus.

VUE INFORMATIONNELLE
VUE DES RESSOURCES
VUE ORGANISATIONNELLE
VUE FONCTIONNELLE
Evnement Processus
Activit
Cellule
dorganisation
Unit
dorganisation
Ressource
Ensemble
daptitudes
Vue dobjet
Objet
dentreprise
dclenche
gnre est compos de
est responsable de
fournit
est responsable
pour
est compos de
a pour
entre/sortie
est dfinie par
requiert
Figure 11. Vues dentreprises (Vernadat 1999)

4. Notions autour du terme processus
Sadapter la globalisation et une demande versatile, pouvoir amliorer constamment son
efficacit et modifier rapidement sa chane de valeur sont les dfis que cherchent relever les
entreprises depuis plusieurs annes. Afin de rester comptitive, une entreprise doit tre capable de
dcrire et de demeurer ractive face un vnement endogne ou exogne. Une telle flexibilit peut
sobtenir en dcrivant en processus les fonctionnalits dune entreprise.
Ce chapitre prsente les diffrentes notions accompagnant le terme processus. Il dcrit galement
le cycle de vie dun processus et les diffrentes tapes qui le jalonnent.

C
H
A
P
I
T
R
E

4

4.1 PROCESSUS
Afin de raliser une dmarche qualit, lapproche processus est recommande aux entreprises par
la norme ISO 9000 : 2000
8
. Un processus est alors dfini comme tant un ensemble dactivits
corrles ou interactives qui transforme des lments dentre en lments de sortie . La dfinition dun
processus dentreprise selon (Morley, Hugues, Leblanc, & Hugues 2007) nous semble tre la plus
adquate :

Un tel processus est reprsent Figure 12.

Gnralement, nous adoptons la typologie de (Debauche & Megard 2004) pour diffrencier les
processus dentreprise selon trois catgories :
- Les processus de pilotage ou de management ont pour but dorganiser les objectifs
stratgiques de lentreprise.
- Les processus oprationnels ont pour fonction daccomplir une mission dans un domaine
donn et utilise plusieurs fonctions de lentreprise.
- Les processus de support ou de soutien sont priphriques au mtier de lentreprise et ne
participent quindirectement laccomplissement dun objectif mtier.
(SPINOV 2006), (ISO TC 184/SC 5 2000) indiquent quune quatrime catgorie de processus peut
tre considre, les processus de mesure qui fournissent les mtriques ncessaires lvaluation des
processus et leur amlioration continue. Cette typologie est reprsente Figure 13.

8
ISO : International Organization for Standardization, http://www.iso.org
Un processus dentreprise est un ensemble dactivits, entreprises dans un
objectif dtermin. La responsabilit dexcution de tout ou partie des
activits par un acteur correspond un rle. Le droulement du processus
utilise des ressources et peut tre conditionn par des vnements
dorigine interne ou externe. Lagencement des activits correspond la
structure du processus.
Activits,
Tches
Evnements
Sortie
Entre
Acteurs
Ressources
Figure 12. Processus dentreprise (Morley et al. 2007)
4. NOTIONS AUTOUR DU TERME PROCESSUS 45

Si (Debauche & Megard 2004) prend bien en compte ces fonctionnalits, il les inclut directement
dans les processus de pilotage : Ils [les processus de pilotage] observent aussi les processus
oprationnels et de support pour analyser leur performance, , et pour ventuellement les faire voluer.

4.2 PROCESSUS MTIER
Les processus mtier sont les processus reprsentatifs des activits de lentreprise, de sa chane
de valeur. Diffrentes dfinitions ont t nonces au sujet des processus mtier. Voici ce qui merge de
ces dfinitions.
Les processus mtier ont pour fonction dorchestrer les activits participant laccomplissement
dun but ou objectif de lentreprise. Les activits dun processus mtier sont excutes par des acteurs
jouant des rles particuliers, consommant et produisant des ressources. Les activits peuvent tre
dclenches par des vnements et peuvent leur tour produire des vnements. Les activits dun
processus peuvent tre lies par des dpendances de ressource (dpendances de producteur-
consommateur) ou des dpendances de commande (une activit dclenchant une autre). Les acteurs
oprent lintrieur des frontires des organisations qui excutent des fonctions mtier spcifiques. Les
rles peuvent soutenir des fonctions.
Le mtamodle propos par (Morley, Hugues, Leblanc, & Hugues 2007) permet de voir la
structuration de ces diffrents concepts entre eux (Figure 14).
Processus de pilotage
Processus de support
Processus oprationnels
P
r
o
c
e
s
s
u
s

d
e

m
e
s
u
r
e

F
o
u
r
n
i
s
s
e
u
r
s

D
i
s
t
r
i
b
u
t
e
u
r
s
/

C
l
i
e
n
t
s

Processus oprationnels
Figure 13. Typologie des processus

Dans la suite du manuscrit, nous considrons la dfinition suivante du processus mtier :

Lexemple de la Figure 15 est constitu de trois processus mtier : Vente du produit p ,
Gestion des stocks et Production du produit p .
Par nature, un processus dentreprise possde une dimension horizontale. Cette dimension est
multi-domaine. Par exemple, la Figure 15 peut tre perue comme la reprsentation du processus
Gestion du produit p . Ce processus est multi-domaine, il dpend des dpartements Ventes ,
Stocks et Production dune entreprise. Un processus possde galement une dimension verticale,
variant selon le degr de spcification recherch par le modlisateur. Ainsi, la Figure 15 peut reprsenter
la gestion du produit p (niveau stratgique), contenant le sous-processus Vente du produit p , lui-
mme contenant lactivit Rserver p (niveau oprationnel).
A travers cet exemple, nous constatons que le processus dentreprise intgre la chane de valeurs
de manire transversale.
Processus Objectif
Global Dtaill
Activit Transition
Entre
Rsultat
Ressource
Evnement
Tche Acteur
se dcompose en
1..*
1..*
1..*
1..*
*
*
*
*
*
*
*
*
*
*
*
*
1
1
1
1
1
rpond
dbut
comprend
fin
est attribu se compose de
est suivie de
Figure 14. Mtamodle du processus mtier selon (Morley, Hugues, Leblanc, & Hugues 2007)
Un processus mtier est une orchestration dactivits, incluant une
interaction entre diffrents acteurs sous la forme dchange dinformations,
ralisant des objectifs mtier.

4.2.1 Processus mtier et SI
Les processus mtier permettent dorganiser et de rpartir les tches entre les diffrents acteurs
dune entreprise. Ceci contribue la ralisation des objectifs stratgiques de celle-ci. Ce processus
mtier obit galement des rgles et procdures reprsentant le point de vue organisationnel de celui-
ci. Un processus mtier est mis en uvre laide du SI de lentreprise. Ainsi, un processus mtier peut
tre dcompos en un ou plusieurs processus SI selon (Morley, Hugues, Leblanc, & Hugues 2007).

Ces processus SI reprsentant tout ou partie du processus mtier participent aux mmes objectifs
mais se focalisent sur la mise disposition et le traitement de linformation. Ces processus SI sont mis en
uvre par des processus informatiques, soit un ensemble dactivits logicielles, excutes par des
machines et dialoguant ventuellement avec des humains.
Larticulation de ces diffrents concepts est reprsente Figure 16.
Processus Production du produit P
Processus Gestion des stocks
Processus Vente du produit P
Activit 1 Rserver P
Activit
3
Activit
n
Activit 1
Modification
Stock
Contrle
Stock
Activit
m
Activit 1
Activit
2
Activit
o
Dcrmenter Stock P Incrmenter Stock P
Lancer production P
Figure 15. Exemple de processus mtier
Processus
mtier
Ressources
Procdure
Processus SI
Entits
Objets
informatiques
Processus
informatique
est traduit en
est vue de
s'appuie sur
ralise
0..*
1..*
1..*
0..*
0..1 0..1
0..*
0..*
Figure 16. Processus mtier, processus SI, processus informatique

4.2.2 Processus mtier, processus fonctionnel, procdure
Aprs avoir expos la typologie des processus mtier Figure 13, nous dfinissons ses diffrents
niveaux dabstraction Figure 17 :

Selon (Debauche & Megard 2004), il faut resituer le processus mtier selon les trois niveaux dune
entreprise :
- Le niveau mtier : o se trouvent les processus stratgiques de pilotage ainsi que les
processus oprationnels ;
- Le niveau fonctionnel : o se situent les processus oprationnels et de support. Nous y
trouvons, dans une moindre mesure, les processus informatiques dintgration interentreprise et
interapplication ;
- Le niveau informatique : dans lequel se trouvent les procdures, des activits limites dans
lespace et le temps.
Nous remarquons que (Debauche & Megard 2004) ralise une sparation franche entre processus
fonctionnels et processus mtier. Or, nous considrons quun processus oprationnel peut intervenir un
niveau mtier ou un niveau fonctionnel.
Mtier
Processus
mtier
Fonction
Processus
fonctionnel
Activit Procdure
Activation
Produit/service
Ressources
Prend en charge
Met en oeuvre
Prend en charge
Met en oeuvre
Prend en charge
Met en oeuvre
orchestre
orchestre orchestre
orchestre
se dcompose en
Vue fonctionnelle
Vue informatique
Vue mtier
dclenche
produit
produit
consomme
Figure 17. Niveaux dabstraction du processus mtier

REMARQUE : PROCESSUS, PROCESSUS METIER, PROCESSUS DENTREPRISE
Dans la suite du manuscrit, nous utiliserons les termes processus mtier et processus pour dsigner lensemble des
processus dentreprise : processus de pilotage, processus fonctionnel, processus de support, processus de mesure.

4.3 CYCLE DE VIE ET ACTEURS
Durant son cycle de vie, le processus mtier volue, et est manipul par diffrents acteurs. Dans
cette section, nous dcrivons de manire gnrique les principales tapes jalonnant le cycle de vie dun
processus. Nous verrons plus tard comment ces diffrentes tapes seront interprtes par les systmes
de gestion type workflow et BPM section 6.1.
4.3.1 Cycle de vie
Le cycle de vie dun processus mtier est dcrit Figure 18. Ce cycle hrite directement des
concepts appartenant aux cycles de vie workflow, eux-mmes hritant des concepts issus de
lautomatique.
Les diffrentes tapes de ce cycle de vie sont ralises dans deux domaines bien distincts : le
domaine mtier et le domaine SITI. Les tapes appartenant au domaine mtier sont relatives lanalyse,
la modlisation et loptimisation du processus. Lobjectif recherch par les tapes seffectuant dans le
domaine SITI est essentiellement un objectif dautomatisation du processus : son implmentation, son
excution et le prlvement de donnes relatives son excution. Lingnierie des processus mtier
reprend lensemble de ces tapes quil regroupe selon trois grandes phases : une phase danalyse,
dexcution et de surveillance. Nous prsentons plus en dtail les mthodes et outils lis cette
discipline chapitre 6.
4.3.2 Acteurs
Jusqu rcemment, les premiers cycles de vie ne distinguaient pas le domaine mtier du domaine
SITI. Il ny avait pas de sparation franche entre limplmentation technique et la reprsentation
conceptuelle dun processus, notamment au sein de systmes de gestion de type workflow (Van der
Aalst 2004), (Heilmann, 1997). Au dbut des annes 2000, larrive de lingnierie des processus mtier
a modifi la perception des acteurs intervenant sur les processus.
Les deux acteurs ncessaires laccomplissement dun cycle dingnierie de processus peuvent
facilement tre identifis, lanalyste mtier et lexpert SITI. Un analyste mtier recherche de nouvelles
faons damliorer lefficacit mtier de son entreprise. Cette amlioration peut tre ralise en
modifiant la manire de travailler collectivement, en changeant doutils ou de processus (Various IIBA
and Brennan 2008). Dans ce manuscrit, nous supposerons que lanalyste mtier produit
systmatiquement un modle juste selon les critres dfinis par son domaine. Lexpert SITI prend en
charge ces besoins mtier et les transforme selon des considrations techniques. A travers lapproche
que nous proposons dans ce manuscrit, nous mettons en avant limportance de ces acteurs et la

contribution quils peuvent apporter afin de diminuer lcart entre domaine mtier et domaine SITI et ainsi
permettre un alignement oprationnel tel que dfini dans la section 2.2.

P1 : Multi-domaine
Un processus mtier doit rester comprhensible et manipulable par des
acteurs de domaines diffrents.
4.4 MODELISATION PAR LES PROCESSUS : IMPORTANCE DE LA VUE FONCTIONNELLE
Si les modles de processus intgrent gnralement plusieurs vues, la perspective fonction de
lentreprise demeure llment essentiel de lanalyse dans la plupart des mthodologies, en se
rapprochant le plus de la dfinition du processus de gestion dcrit par (Scheer, 2002). Le processus est
alors dcrit selon les fonctions excuter et le squencement entre ces fonctions. Ce squencement
reprsente le flux des fonctions dirig par un flux de contrle dcrivant les vnements influenant le
dclenchement et lenchainement logique des fonctions. Cette logique est dfinie au pralable selon les
objectifs mtier de lorganisation et lexpertise professionnelle des acteurs de lentreprise. Nanmoins,
ces pratiques professionnelles restent limites par les contraintes technologiques associes au mtier.
Objectifs,
analyse
environnemental
analyse
organisationnelle
Conception du
processus
Implmentation du
processus
Simulation
Excution du
processus
Surveillance du
processus
Evaluation du
processus
Mesures
Mtriques du
processus
Mtriques
cibles
Autres types
de rapports
Mtriques du
processus
Processus
implment
Modles de
processus
Valeurs cibles
Mesures pour
amlioration
Analyste mtier
Expert SITI
Domaine mtier
Domaine SITI

Figure 18. Cycle de vie du processus mtier, inspir de (Zur Muehlen 2004)

4.5 CONCLUSION
Ce chapitre montre comment la relation entre lentreprise et son informatique devient importante de
par ses processus troitement lis son systme dinformation.
Selon de nombreux auteurs, ce nest pas le concept de processus qui est nouveau mais la
convergence de techniques informatiques qui permettent de grer aujourdhui le cycle de vie complet des
processus mtier de lentreprise : identification, modlisation, dploiement, excution, opration, analyse
et optimisation des processus mtier. Ainsi, grer une entreprise travers ses processus nest pas une
rvolution en soi. Une approche oriente processus repose en grande partie sur lexprience mature de
lindustrie dans le domaine de la planification et de la gestion des processus de fabrication.
Une telle approche demeure efficace lorsque le processus modlis possde une structure
formellement dfinie pouvant tre dcrite selon une squence vnementielle de processus/activits.
Cependant, les processus dentreprise rencontrs ne remplissent pas forcment ces critres. Il existe
ainsi des processus dordre conceptuel possdant une description informelle. Dans ce cas, les fonctions
le constituant ne sont rellement dfinies quau moment du dploiement du processus. Nous parlerons
de processus peu structur dont la modlisation reste partielle dun point de vue des SITI. Nous verrons
dans le chapitre 6, que lingnierie des processus mtier, ou BPM, svertue rduire lcart existant
entre domaines mtier et SITI. Pour cela, il faut tre en mesure de reprsenter et diriger les processus, et
ce tout au long de leur cycle de vie. Nous prsentons dans le chapitre suivant les principaux paradigmes
et outils portant sur lutilisation et la manipulation des modles de processus.

5. Ingnierie et Architecture Diriges par les Modles
Les disciplines et mthodes pour le dveloppement et la maintenance des systmes
prpondrance logicielle reposent sur lutilisation de modles abstraits partir desquels sont gnrer
dautres modles ainsi que du code informatique. Afin dy parvenir, lObject Management Group - OMG a
propos en 2000 une nouvelle approche : lArchitecture Dirige par les Modles. Cette approche a
volu en une approche intgrative plus gnrale, lIngnierie Dirige par les Modles. Dans ce
chapitre, nous dcrivons les concepts rgissant lIngnierie Dirige par les modles. Nous dcrivons
galement lapproche reconnue comme une spcialisation de lIDM, lArchitecture Dirige par les
Modles.

C
H
A
P
I
T
R
E

5

5.1 INGENIERIE DIRIGEE PAR LES MODELES
LIngnierie Dirige par les Modles (IDM) - ou Model-Driven Engineering, MDE - est une approche
intgrative gnrale (Favre et al. 2006), (Perez et al. 2006), (Combemale 2009) mettant disposition
des outils, concepts et langages pour crer et transformer des modles. Evolution rsultant de lapproche
MDA, initiative de lOMG comme explique dans le paragraphe 5.2, lIDM permet dintgrer diffrents
espaces techniques, quils sagissent de technologies orientes objet (reposant UML) ou de documents
structurs (reposant XML).
La majorit des mthodes de modlisation dfinit des modles contemplatifs, essentiellement
utiliss dans des buts de communication et de comprhension entre agents/ acteurs humains. Pour que
ces modles deviennent interprtables et excutables par une machine, il faut les transformer. Pour y
parvenir, il est ncessaire de formaliser les modles, les transformations quils subissent, les langages de
reprsentation et les mtamodles qui y sont associs. Lide principale propos par lIDM est de pouvoir
utiliser autant de langages de modlisation diffrents, nomms Domain-Specific Modeling Languages DSML,
que le ncessitent les aspects technologiques utiliss. LIDM propose galement lutilisation systmatique
des mtamodles, des modles et des processus de tissage de conception suffisamment prcis et
formels, pour tre interprts ou transforms par des machines.
5.1.1 Systme rel, modle, mtamodle
Les liens existants entre systme rel, modle et mtamodle sont reprsents dans la Figure 19.
Dans le niveau M
0
se situe le systme rel. Au niveau M
1
, un modle reprsente une simplification de ce
systme. Ce modle doit tre conforme un langage dexpression, dfinit par son mtamodle au niveau
M
2
(Bzivin 2004), (Favre, Estublier, & Blay-Fornarino 2006).

La Figure 19 montre galement une reprsentation simplifie dune maison travers les diffrents
niveaux dabstraction. Ici, le systme rel est la maison (niveau M
0
) qui est reprsente par un plan
darchitecte (niveau M
1
). Ce plan utilise une lgende (des symboles) et des conventions de
reprsentation (des contraintes) qui sont dfinis par le mtamodle (niveau M
2
).
Mode rel
Monde des
modles
Mtamodle
Systme rel
Modle
Niveau M2 :
Dfinition des symboles
du plan et de leurs
relations
Niveau M1 :
Plan darchitecte
Niveau M0 :
Une maison
EstConformeA
Reprsentationde
Figure 19. Systme rel, modle, mtamodle
5. INGENIERIE ET ARCHITECTURE DIRIGEES PAR LES MODELES 55

5.1.2 Processus de tissage de conception
Le processus de tissage de conception reprsente lensemble de transformations partiellement
ordonn permettant lobtention dun artefact excutable. Chacune de ces transformations prend des
modles en entre et produit des modles en sortie. Lutilisation dun tel processus augmente lagilit de
la conception de produit. En effet, lorsquun nouveau produit doit tre driv, qu'il sagisse dune
volution ou variante d'un produit existant, nous nous contentons de rutiliser la majeure partie du
processus de conception, quelques dtails prs.
5.2 ARCHITECTURE DIRIGEE PAR LES MODELES
Spcialisation de lIDM prsente par lOMG en 2000, lArchitecture Dirige par les Modles ou
Model Driven Architecture MDA, sappuyait initialement sur le standard UML pour dcrire sparment les
parties dun systme logiciel indpendamment des plates-formes spcifiques les mettant en uvre. En
quelques annes, ce projet sest toff, ce qui permet la parution de la spcification version 1.0.1 de
MDA en 2003.
MDA reprend la dmarche en Y - 2 Tracks Unified Process, 2TUP. 2TUP est un processus de
dveloppement logiciel pour la description de larchitecture logicielle, en particulier la modlisation des
systmes dinformation (Roques and Valle 2004). Laxiome fondateur de cette approche est de diviser
sa dmarche en deux branches : fonctionnelle (approche par les fonctionnalits) et technique (tude de
la mise en uvre).
MDA (Kadima 2005) suggre une nouvelle approche mettant en avant lutilisation systmatique de
modles comme support la conception et au dveloppement de diffrents types de systmes. Pour
dfinir une sparation probante entre le domaine mtier dune entreprise, des logiciels et de plates-
formes technologiques des systmes d'information, et donc sparer les contraintes fonctionnelles des
contraintes techniques, MDA utilise trois types de modles, chacun d'entre eux situs niveaux
d'abstraction trs diffrents. Ces types de modles sont les Computation Independent Models - CIM, Plateform
Independent Models - PIM et PlatformSpecific Models - PSM (Figure 20).

Figure 20. Les modles MDA selon lapproche 2TUP

A titre dexemple au sein des travaux Easy-Dim, (Touzi 2007) exploite cette dmarche afin de
raliser un Systme dInformation Collaboratif SIC.
5.2.1 Rles des CIM, PIM et PSM
Les CIM dsignent les modles les plus abstraits. Daprs (OMG 2003), ces modles sont
associs aux exigences dun systme et/ou un domaine mtier. Plus prcisment le CIM dcrit
usuellement lenvironnement, les processus mtier et objets ainsi que les exigences spcifiques du
systme. Il permet de dfinir les rgles et le vocabulaire mtier et reprsente laspect organisationnel du
systme.
Les PIM dcrivent tout ou partie des fonctionnalits du systme modlis sans se soucier des
dtails techniques (Panetto 2006). Le PIM est donc un modle conceptuel indpendant de toutes
considrations lies la plateforme cible, son langage ou la technologie usite. Le PIM capture
laspect logique du processus mtier, en respectant les rgles haut niveau dcrites par le CIM.
Ces PIM sont techniquement enrichis afin d'obtenir par gnration un PSM. Le PSM est
associ une plateforme spcifique base sur une technologie bien dfinie, plateforme dcrite par un
PlateformModel - PM. Concrtement, le PSM peut tre li un systme, un langage, ou une technologie
particulire, contrairement au PIM. Cette tape est indispensable la gnration du code et donc
l'implmentation du processus cible selon lapproche MDA.
Ces diffrents modles et les rles qui leur sont attribus sont rsums Figure 21.

Les diffrentes tapes lors de la transformation dun processus modlis un processus
implment travers MDA sont reprsentes Figure 22.
Business
Preoccupation
MDA terms
Computation
Independent
Model
Platform
Independent
Model
Platform
Specific
Model
Business
Model
Logical
System
Model
Technology
Specification
Figure 21. MDA adapt de Model-driven.org

Il convient de noter que MDA nest pas un standard mais un paradigme de dveloppement se
reposant sur dautres standards de lOMG comme MOF, UML, XMI que nous allons dcrire brivement
dans le paragraphe suivant.
5.2.2 MOF, UML, XMI
Pour favoriser l'interoprabilit entre ces modles, lOMG promeut lutilisation du mtalangage
orient objet le Meta Object Facility - MOF (OMG 2003). Le MOF fournit un socle sur lequel les langages
de modlisation peuvent se baser travers une nouvelle couche dabstraction : le mta-mtamodle. Il
fournit des concepts de mtamodlisation standardiss et dfinit quatre couches dabstraction (M0-M3)
(Figure 23). Ce mtalangage supporte la dfinition de mtamodles en tant quensembles de structures
orientes objet (les classes, les packages et les oprations). Il fournit galement des constructions
spcifiques aux modles comme par exemple la contenance dune classe dans une autre, ou encore
lassociation.
Son utilisation a t popularise par lEssential MOF - EMOF, issu du framework de modlisation
Eclipse, Eclipse Modeling Framework - EMF. Le MOF prconise la cration dun langage spcifique pour
un problme de domaine spcifique et ceux laide de mtamodles.
Parmi les langages de modlisation compatibles avec le MOF, il en est un mettre en vidence,
lUnified Modelling Language - UML. UML couvre la majorit des facettes connues du dveloppement de
logiciels orients-objets et orients composants. La mta-modlisation avec UML se ralise laide de
profils, substituts de mtamodles. Un profil redfinit les concepts UML afin de sadapter des besoins
spcifiques : des strotypes et des valeurs taggues peuvent tre appliqus aux diffrents lments
dun modle, comme par exemple le profil SysML pour lingnierie systme (Fontan 2008).
Approche dirige par les modles
Processus modlis
Domaine mtier
Processus implment
Domaine SI
Collecte des
besoins
Analyse Conception Implmentation
CIM PIM PSM Implmentation
Figure 22. Domaine mtier, domaine SI et MDA

De manire permettre lchange de modles MOF et UML entre diffrents diteurs logiciels, le
langage standardis XML Metadata Interchange - XMI a t cr (OMG 2007b).
5.2.3 Limite du MDA
La principale limite du MDA dans notre contexte est quil nest pas assez investi dans le domaine
mtier. Le MDA a t cr dans un but de gnration de logiciels et non dans un but de gestion de
processus mtier. Nous constatons que MDA ne dcrit pas formellement comment les modles mtier
dfinis au niveau CIM doivent tre manipuls et associs aux modles logiques PIM. Dans la littrature,
de nombreux travaux portant sur MDA sont axs sur les modles logiciels, PIM et PSM, (Steel and
Jzquel 2004), (Bzivin and Blanc 2002) sans prendre vritablement en compte le domaine mtier
duquel sont issus les modles CIM. Ainsi, dans certaines utilisations du MDA, l'cart entre le domaine
mtier et SITI nest pas envisag et encore moins rsolu, comme le montre la Figure 24. Pourtant nous
avons prsent limportance des aspects logiciels, du domaine SITI et la stratgie qui laccompagne au
sein dune entreprise. Il faudrait privilgier le domaine mtier comme tant le premier aspect prendre en
compte et grer dans un processus de dveloppement logiciel type MDA.
Dans le cadre de la modlisation d'entreprise, lingnierie des processus mtier est devenue un
point important. Le but de lingnierie des processus mtier est de contribuer diminuer ou au mieux
rsoudre l'cart entre le domaine mtier et le domaine SITI, en particulier lors de ltape de
dveloppement logiciel. Un dveloppement logiciel adapt aux processus mtier rendrait lapplication
dveloppe plus efficiente et plus ractive face aux changements dordre mtier. En dautres termes,
rduire cet cart permettrait daugmenter lalignement oprationnel entre domaine mtier et domaine
SITI.
Modle
MOF
Mtamodle
UML
Mtamodle
IDL
Modle
UML
Interface
IDL
Modle
UML
Modle
UML
Interface
IDL
Interface
IDL
Couche M3
Mta-mtamodle
Couche M2
Mtamodle
Couche M1
Modle
Figure 23. Couches de mta-modlisation selon MOF

5.3 CONCLUSION
De nos jours, les projets mens au sein dune entreprise se distinguent par laccroissement de leur
complexit et dune quantit dinformation toujours plus importante. Ces informations sont apportes par
plusieurs acteurs, exerant des mtiers et possdant des rles diffrents. Afin dtre le plus efficace
possible, lentreprise doit faire preuve dune gestion moderne et pouvoir grer conjointement ses
diffrentes comptences.
Les notions issues de lIDM et de lutilisation du MDA permettent dorganiser cette gestion multi-
domaine et de modles dabstractions diffrentes, de faon fluide et en favorisant au maximum les
formalismes de chacun. Nanmoins le MDA reste limit par rapport au domaine mtier. Le chapitre
suivant aborde la ncessit dvoluer dune approche MDA, surtout utilise pour le dveloppement
logiciel, vers une approche oriente mtier, lingnierie des processus dentreprise ou Business Process
Management.
Gnration du modle
Domaine mtier
Modles mtier -
CIM
Domaine SITI
Modles logiques
- PIM
Modles logiciel -
PSM
Application logicielle
Analyste mtier
Expert SITI
manuelle
automatique
Figure 24. MDA, fracture entre domaine mtier et domaine SITI

6. Ingnierie des processus mtier
Nous exposons comment lingnierie des processus mtier, Business Process Management, met
laccent sur une architecture oriente-mtier . Lintrt dune telle architecture est de fournir une
rponse adapte aux diffrents besoins des utilisateurs, en abordant la question de lamlioration
continue des processus priorisant le point de vue mtier au point de vue technique. En effet, BPM
prconise une vision transverse des processus mtier, de bout en bout , et non une vision morcele
se concentrant indpendamment sur chaque fonction de lentreprise.
BPM fournit ainsi une vritable architecture reposant sur un ensemble doutils et prenant en charge
le cycle de vie dun processus mtier. Il permet de dfinir rapidement et en souplesse des processus
depuis leur analyse leur implmentation, de dterminer leurs objectifs, et de les superviser.

C
H
A
P
I
T
R
E

6

6.1 DE LA GESTION DU WORKFLOW A LA GESTION DES PROCESSUS METIER
REMARQUE
Lingnierie des processus dentreprise ou mtier est souvent reprsent par lacronyme BPM signifiant Business
Process Management. Pour ne pas droger cette rgle et allger le texte, lacronyme BPM sera utilis en lieu et en
place du terme ingnierie des processus dentreprise .

Le Business Process Management est le plus souvent considr et interprt comme une nouvelle
tape, une volution naturelle de la vague workflow des annes 90. Ainsi, la terminologie employe pour
dfinir le BPM est celle appartenant au workflow. La Workflow Management Coalition (WfMC) dfinit le
terme workflowde la manire suivante (WfMC 1999):

Le systme prenant en charge ce workflow, le WorkFlowManagement System- WFMS est dfinit
comme tant :

Ces deux dfinitions mettent laccent sur l'utilisation de logiciels permettant de faciliter l'excution
des processus mtier. Au cours de la dernire dcennie, de nombreux chercheurs et praticiens
commencrent raliser que cette considration traditionnelle des processus devenait trop restrictive. A
la suite de ceci, de nouveaux termes sont apparus comme la gestion des processus mtier, ou Business
Process Management, incluant dans la plupart des cas, la gestion de workflow. La Figure 25 propose
par (Van der Aalst 2004) montre en effet que le cycle de vie dun processus selon BPM englobe les
mmes phases que celui de la gestion du workflow :
- Reprsentation du processus, Process Design,
- Configuration du systme, SystemConfiguration,
- Excution du processus, Process Enactment,
Une des premires diffrences avec le BPM est que ce dernier rajoute une phase de Diagnostic,
Diagnosis, son cycle. La section suivante dcrit les fonctionnalits de ces diffrentes phases au sein dun
cycle dingnierie de processus.
The automation of a business process, in whole or part, during which documents,
information or tasks are passed fromone participant to another for action, according to a set
of procedural rules.
A systemthat defines, creates and manages the execution of workflows through the use of
software, running on one or more workflowengines, which is able to interpret the process
definition, interact with workflow participants and, where required, invoke the use of
Information-Technology tools and applications.
6. INGENIERIE DES PROCESSUS METIER 63

Le BPM offre aux organisations la libert de changer trs rapidement leurs systmes et leurs
processus, sans avoir besoin de redvelopper compltement leurs applications (Crusson, 2003).
Lobjectif du BPM est de garantir une entreprise que ses processus mtier sont adapts de manire
continue un environnement en constante volution (Fingar and Bellini 2004). Le BPM permet aux
entreprises de grer les processus mtier depuis un niveau stratgique jusqu un niveau oprationnel
(Pyke 2006). Peru tel un concept permettant lamlioration de la modlisation et de lintgration des
processus mtier mais galement laugmentation de la productivit et la diminution de cot, le BPM sest
impos comme une discipline part entire. Cette discipline dcrit l'ensemble des activits d'analyse, de
modlisation, de conception, de dveloppement, dexcution, de suivi et optimisation des processus
mtier. Un consensus des diffrentes dfinitions, comme celle de (Malone et al. 2003) ou (Smith et al.
2002), donnerait la dfinition suivante :

REMARQUE : M POUR MANAGEMENT OU POUR MODELLING ?
La modlisation des processus mtier ou Business Process Modelling BPM, dsigne la reprsentation courante (as-is) et
propose (to-be) des processus. Par dfaut, dans ce manuscrit, lacronyme BPM dsigne BPManagement ,
lingnierie des processus mtier.

Dans les sections suivantes, nous dcrivons les diffrentes tapes constituant le cycle de vie dun
processus mtier selon le BPM. Puis nous fournissons une analogie avec un cadre MDA, o nous
observons que BPM permet danalyser, de modliser et grer les processus depuis le niveau CIM vers le
niveau PSM, notamment des lments, comme les acteurs, les ressources, les tches et l'information.
Figure 25. Gestion Workflow et BPM
Le BPM correspond lingnierie des processus de lorganisation, ou
processus mtier, laide des technologies de linformation. Il a pour
vocation de modliser, dployer, excuter et optimiser de manire continue
les diffrents types de processus et ainsi damliorer lagilit dune
organisation.

Les modles obtenus fournissent gnralement une meilleure connaissance du systme et une
simplification de la vision du problme pour les experts techniques. Puis nous concluons sur les
amliorations quapporte lutilisation de BPM mais galement sur les limites qui la contraignent.
6.2 LE CYCLE DE VIE DU PROCESSUS SELON LAPPROCHE BPM
Le BPM possde une nature multidisciplinaire revendiquant une mise en uvre de la thorie la
pratique travers plusieurs vues, dfinitions et perspectives. La prsentation du cycle de vie dun
processus mtier selon BPM permet dassimiler la plupart de ces points. Ce cycle accompagne le
processus depuis sa conception sa ringnierie, voluant en permanence selon les buts mtier qui le
dfinissent ou les modifications de son environnement qui limpactent. Ce cycle dingnierie des
processus comporte trois phases principales comme le montre la Figure 26: la phase Business Process
Analysis, la phase Business Process Implementationet la phase Business Activity Monitoring.

Amliorer
Informatiser Superviser
MOA
MOE
BPA
BPI
BAM
Figure 26. Cycle dingnierie continue des processus, BPM (Debauche
and Megard 2004)

REMARQUE : GESTION OU INGENIERIE ?
Les lecteurs anglophones auront constat quici le terme de management nest pas traduit par le terme gestion, mais
par ingnierie au sens gnie du terme, dsignant lart de lingnieur. En effet, nous pensons que le terme gestion
de processus est trop restrictif pour dcrire lensemble des possibilits offertes par une approche BPM. Le BPM ne
permet pas seulement de diriger les processus. Il permet de considrer un processus sous tous ses aspects, et
regroupe lensemble des fonctions de lingnierie, de sa conception, sa ralisation, son contrle sa ringnierie.
Egalement, cette discipline comprend des langages, mthodes, outils et standards.

6.2.1 Business Process Analysis, BPA
La finalit du BPM est de fournir la direction dune entreprise une matrise accrue dans lexercice
de son mtier. Pour ce faire, les analystes mtier reprsentant la matrise douvrage doivent identifier et
concevoir les processus mtier dont ils sont propritaires. Ainsi, tout effort BPM commence par une
phase de conception de processus. Les processus existants (as-is) doivent tre identifis et les processus
cibles (to-be) doivent tre dfinis. La phase de conception est troitement associe la phase de
modlisation des processus. Durant cette phase, les modles de processus sont dfinis laide dun
langage de modlisation, la plupart du temps graphique et respectant une grammaire structure. Les
modles de processus sont construits selon diffrents points de vue (flux de contrle et de donnes,
aspects organisationnels et socio-techniques). Ces actions correspondent celles ralises dans la
phase Process Design dun WFMS. Comme le cycle BPM est un cycle de vie continu, les processus
modliss sont amens tre modifis et optimiss, sadaptant un environnement fluctuant. Ces
diffrentes analyses sont similaires celles constituant la phase Diagnosis . Une des caractristiques
la plus importante de la dmarche BPM est la possibilit pour un analyste mtier de dfinir les processus
mtier sans aucune comptence technique. Les analystes mtier conoivent les processus par
lintermdiaire dune interface facile dutilisation qui apporte une grande assistance dans la dfinition de
processus mtier complexes. Nanmoins la seule faon dobtenir un processus comprhensible par le SI
est d'ajouter des connaissances techniques lies au domaine SITI de lentreprise.

P2 : Indpendance
des environnements
Un modle source doit tre ralis indpendamment des considrations
de lenvironnement cible.

6.2.2 Business Process Implementation, BPI
REMARQUE : I
Dans la littrature, le I de lacronyme BPI reprsente le terme Integration. Cependant, compte tenu des tches que
cette phase doit accomplir, nous jugeons le terme Implementation plus adquat.


Suite la phase BPA, une entreprise obtient une description informelle ou semi-formelle de ses
processus mtier. Il revient aux experts SITI reprsentant la matrise duvre de rendre les processus
labors prcdemment exploitables par un SI. Pour cela, les experts SITI ajoutent des informations
techniques : le format des messages changs, les protocoles de transport utiliss, les transformations
de donnes effectues, les applications impliques dans le processus, lintgration des utilisateurs
comme participants du processus, etc.

P3 : Prise en considration
des modifications apportes
Un modle dimplmentation est souvent modifi avant dtre
excut. Notre approche doit pouvoir en tenir compte.
Ceci fait, le modle BPI peut tre implment sur un large choix dapplications logicielles : les
moteurs dexcution de processus. Nous pouvons les regrouper en trois catgories selon (Debauche &
Megard 2004) :
- Dveloppement maison ou sur mesure : lapplication mtier est directement gnre
par la dfinition du processus mtier. Il sagit dun dveloppement spcifique et dune
transformation unilatrale. Une fois le code gnr puis modifi, nous ne pouvons pas redfinir le
modle conceptuel au sens rtro-ingnierie.
- Mise en place dun ou plusieurs progiciels applicatifs : les experts SITI configurent les
progiciels afin dobtenir les processus voulus par les analystes mtier. Cette personnalisation reste
toutefois limite par les fonctionnalits fournies par les diffrents progiciels et demeure incomplte.
Lentreprise sadapte alors le plus souvent au progiciel au dtriment de ses caractristiques mtier.
Une question se pose alors, lentreprise doit-elle sadapter au progiciel et ses processus
embarqus afin dassurer son alignement ? De plus, lutilisation de plusieurs progiciels
(Enterprise Resource Planning) afin de fournir une couverture fonctionnelle la plus complte
possible au mtier de lentreprise risque de crer des lots fonctionnels au sein du SI, inaptes
communiquer entre eux.
- Mise en uvre dun systme spcifique de gestion des processus Business Process
Management System (BPMS) : est une plateforme logicielle de production pour modliser,
excuter et superviser les processus de bout en bout de lorganisation Cette solution permet de
considrer les modles des processus issus du BPA et de gnrer les applications mtier
adquates. Le BPMS est dcrit plus en dtail en fin de ce chapitre.
Le choix et la paramtrisation de lapplication logiciel correspond la phase System
Configuration dun WFMS. Lexcution du processus rsultant correspond au Process Enactment .
6.2.3 Business Activity Monitoring, BAM
Un des buts principaux de BPM est de procurer un contrle et une amlioration constants des
processus mtier. Les processus peuvent effectivement tre suivis en temps rel. Leur excution
contrle par le moteur de processus paramtr lors du BPI gnre une source considrable de mesures
concernant par exemple les dlais, les ressources, les cots,.... Le BAM fournit un ensemble de
concepts, pratiques et technologies qui assurent le pilotage de lentreprise par un ensemble dindicateurs
danalyse de performance, Key Performance Indicators (KPI), mtriques calcules sur la base des mesures

obtenues prcdemment. Les analystes mtier ont besoin de ces indicateurs complets sur les diffrentes
instances des processus quils suivent (en cours ou termins). Ces KPIs permettent de comparer le
droulement des activits bases sur les processus par rapport aux rsultats attendus. Durant cette
tape danalyse, nous identifions les problmes que nous dsirons rsoudre. Nous proposons galement
les amliorations vis--vis de lefficacit des processus. Nous retrouvons ici le lien avec le BPA et la
phase Diagnosis dun WFMS. Le BAM regroupe des mthodes qui modifient considrablement les
approches actuelles daide la dcision en ceci quelles travaillent directement sur des donnes relles
du systme dinformation (par opposition aux entrepts de donnes) et ceci selon un traitement en temps
rel.
6.3 DU MDA AU BPM
Nous avons dcrits dans les sections prcdentes deux approches permettant la modlisation des
processus, le MDA et le BPM. Nous allons maintenant dcrire et identifier les liens existants entre leurs
diffrents lments.
Le CIM a t dcrit comme tant un modle mtier dfinissant les rgles et le vocabulaire mtier
utiliss par le processus. Nous pouvons ainsi associer un CIM avec le modle mtier obtenu durant la
phase BPA. Mais, ce stade, le modle mtier demeure incomplet sans une description du flux de
contrle de ses processus. Cette information est contenue dans les PIM. En effet, les PIM contiennent les
informations relatives aux fonctionnalits du processus modlis ainsi que leur orchestration.
Lassociation dun CIM et dun PIM permet dobtenir un modle de type BPA.
Le PSM est une tape critique de gnration de code. Le processus modlis est rendu
comprhensible et implmentable sur lapplication cible. Il sagit typiquement des objectifs fixs par
ltape BPI. En consquence, un PSM peut tre identifi avec le modle dimplmentation BPI.
Ces diffrentes association sont reprsentes Figure 27.
Nanmoins, lanalogie sarrte l (Smith 2003). BPM et MDA nont pas t conus pour raliser les
mmes objectifs. MDA a t conu pour permettre la conception et la gnration dunits logicielles
assistes par ordinateur. BPM permet lingnierie des processus.

BPA Model CIM+PIM
BPI Model - PSM BAM
Figure 27. MDA et BPM

6.4 SUITES BPM
Des outils spcifiques pour mettre en uvre un cycle BPM sont les suites BPM ou Business Process
Management Suite BPMS (le s est parfois considr comme reprsentant le terme system). Larrive
des BPMS marque une volution dans la structuration des applications du SI de lentreprise.
6.4.1 Une volution ncessaire
Les architectures deux tiers de type client-serveur, trois tiers puis n-tiers de type web services ont
permis la sparation de la couche prsentation (client lger, lourd ou riche), de la couche application
(rgles et traitements) et de la couche donnes (SGBDR, ERP, legacy softwares, EAI ) (Figure 28(a)).
Nanmoins, les processus et la logique mtier qui leur est associe, restent noys dans la logique
applicative. Il en est dailleurs de mme avec les rgles mtier. Lextraction des processus et des
dcisions dissimules dans les applications reste dlicate. Ainsi les BPMS simposent comme une
nouvelle couche du systme dinformation et visent en extraire les processus (voire galement les
dcisions ou rgles mtier) selon les mmes raisons qui ont motiv dans les annes 90 les informaticiens
extraire des applications les donnes dans les SGBD (Figure 28(b)). Lextraction des processus mtier
des applications du systme dinformation, notamment des ERP doit permettre lorchestration des
activits dun processus interne lentreprise.

6.4.2 Dfinition
Une suite BPM est une plateforme intgre dun diteur unique rassemblant tous les composants
ncessaires au dveloppement et lexcution dune solution BPM : modlisation et analyse,
orchestration automatise, tches humaines, intgration des applications, rgles mtier, et supervision.
Pour certaines catgories mtier, un BPMS peut galement se voir attribuer des composants comme la
gestion de projet, la gestion de cas, les outils de collaboration,
En peu dannes, de nombreux diteurs dapplications se sont intresss au BPMS et ont
contribu au dveloppement doutils sy approchant. Au dpart, les solutions BPM taient vendues sous
forme de modules se compltant les unes aux autres (un module servant lanalyse des processus, un
autre leur monitoring). En 2003, lentreprise de conseil amricaine Gartner identifie cette nouvelle
Gestion de bases de
donnes
Application et
composants
P
r
s
e
n
t
a
t
i
o
n

Gestion de bases de
donnes
Application et
composants
P
r
s
e
n
t
a
t
i
o
n

BPM
(a)
(b)
Figure 28. Dune architecture n-tiers une architecture n-tiers dirige par les processus

gnration doutils BPM comme tant des produits BPM pure-play , coordonnant les interactions entre
utilisateurs, systmes et donnes. Ces outils sont rapidement devenus concurrentiels et quivalents
des outils de gestion du workflow. Ainsi des diteurs workflows et dIntgration dApplications dEntreprise
( ou Enterprise Application Integration EAI) sont entrs dans le march des BPMS. Enfin des diteurs
dapplications plus larges, notamment darchitecture et de modlisation dentreprise ont rejoint cette
mouvance.
La Figure 29 reprend lvolution des BPMS et des principaux diteurs y participant, en sinspirant
de ltude men par (Silver 2008).

REMARQUE : APPROCHE BPM MAIS CYCLE DE VIE DIFFERENT
Aujourdhui des diteurs spcialiss, Software AG IDS Scheer, IBM Telelogic, MEGA, W4, Intalio, Bizagi,
proposent des plateformes logicielles intgrant un ensemble doutils supportant une dmarche BPM. Par exemple
lditeur ARIS dfinit son approche BPM par ARIS Methodology qui comprend quatre phases ( BP Strategy, BP
Design, BP Implementation, BP Controlling ).

Ct logiciel libre, nous notons larrive en 2009 dune jeune pousse franaise, BonitaSoft, qui
dlivre le BPMS, Bonita (Garcs et al. 2009), en partenariat avec lINRIA.
Editeurs BPM Pures
Ex :Savvion, Lombardi,
Appian,
Editeurs Workflow et EAI
Ex: TIBCO, Global 360,
Pegasystems, BEA,
Editeurs dinfrastructure plus large,
de middleware, dentreprise
Ex : IBM, SAP, Oracle
BPMS
Complexit
Temps
2003 2008
Figure 29. Evolution du march BPMS

6.4.3 Structure
Sil existe, ce jour, de nombreux diteurs de BPMS de maturit diffrente, la structure de cette
plateforme intgre dcrite Figure 30 reste identique. Le modle de processus est dploy sur le moteur
de processus, qui assigne les tches aux utilisateurs (cadre Tches humaines ), excute les rgles
mtier (cadre Rgles mtier ), intgre les autres plateformes dexcution (cadre Intgration ). Le
moteur de processus collecte galement les donnes d'excution et constitue les mtriques permettant la
surveillance des processus, dans les tableaux de bord BAM. Lensemble de ces informations peut tre
rinject dans le modle, permettant l'amlioration itrative du processus.
Il convient de rappeler quun BPMS nest pas un empilement de composants interchangeables,
mais essentiellement une plate-forme intgre dit par un seul fournisseur.

6.4.4 Classification
Selon (Silver 2008), nous pouvons grossirement distinguer deux types de processus : les
processus integration-centric, bass sur lintgration et les processus human-centric, bass sur lhumain. Nous
pouvons ainsi classer un BPMS selon les caractristiques des processus quil implmente. Nanmoins, il
BPI
Acteur mtier
BAM
BPA
BAM
Modlisation
Dveloppement
ERP
Middleware SOA
Moteur dexcution de processus
Application legacy
Utilisateur Utilisateur Utilisateur
Rgles
Tches humaines
Intgration
Rgles mtier
Donnes performance
Analyste mtier
Expert SITI
Figure 30. Structure BPMS

revient de considrer que tout (ou presque tout) processus contient la fois des tches humaines et de
lintgration dapplication.
BPMS pour processus human-centric : BPMS-HC
Les processus human-centric sont des processus mettant laccent sur le travail effectu par les
acteurs mtier. Ainsi le rle dun BPMS human-centric BPMS-HC est daffecter et daccompagner
les activits des employs dune entreprise et den mesurer la performance. Cette classification peut elle-
mme tre classe en deux sous catgories : BPMS-HC orient workflow de production et BPMS-HC
orient gestion de cas.
La catgorie workflow de production dsigne les processus mtier connus et dont le flux de
contrle est constitu dactivits bien dfinies et bases sur des rgles mtier. Il sagit la plupart du temps
de processus structurs comme par exemple des ordres de paiements, ou un centre dappels. Plusieurs
instances dun processus peuvent tre cres puis excutes. Le but dun BPMS orient workflow de
production est doptimiser leur temps de cycle, leur nombre dexcution par jour et leur cot.
Au contraire, la catgorie gestion de cas regroupe les processus ncessitant un travail collaboratif
rsolu en temps rel et dune manire plus ad hoc. La gestion de cas regroupe les processus non-
structurs comme les projets, dont le but est clairement fix mais pas les diffrentes tapes pour
latteindre. Lobjectif dun tel BPMS est doptimiser la prise de dcision ainsi que la conformit avec les
lois et rglements tout en autorisant une certaine flexibilit parmi les tapes prendre.
BPMS pour processus integration-centric : BPMS-IC
Un BPMS integration-centric est orient optimisation de lintgration mtier. Ainsi
limplmentation mtier est plus technique et lorientation de dveloppement plus traditionnelle. Ce type
de BPMS favorise lagilit et linteroprabilit entre les diffrentes applications de lentreprise : ERP,
chane logistique, CRM ... Il est plus optimis dtecter et rparer les erreurs en temps rel que de
mesurer les performances des tches humaines.
6.4.5 Conclusion sur les BPMS
Les BPMS sont devenus les outils ncessaires une mise en uvre complte de lapproche BPM.
Pour rendre une suite BPM oprable, il faut systmatiquement paramtrer les diffrentes applications la
composant. Afin de rendre la communication possible entre ces diffrents composants logiciels dun
BPMS, la solution est le plus souvent mono-diteur.
Lentreprise et donc la nature de ses modles tant en perptuelle volution, elle doit pouvoir
sadapter diffrents diteurs ou de nouvelles technologies. A linverse dune approche intgre de
modlisation base sur un atelier logiciel unique, se traduisant par une dpendance lditeur,
lentreprise doit conserver la possibilit de modifier loutil de modlisation voire la plateforme dintgration.

P4 : Evolution des outils
La solution propose doit permettre une volution des outils de
modlisation et des plateformes dexcution.

Il faut galement signaler que les BPMS ne renferment pas systmatiquement une formalisation
des niveaux M
1
et M
2
via une approche IDM formalise et outille.
6.5 LES LIMITES DU BPM
Le BPM propose une dmarche empirique permettant la capitalisation des processus mtier. Son
cycle dingnierie inclut des tapes qui peuvent dpendre du domaine mtier de lentreprise ou de son
domaine SITI. Ceci devrait contribuer rduire lcart existant entre ces domaines. Cependant, une
relation systmatique entre le BPM et le SI de lentreprise reste difficilement ralisable. Lutilisation dun
BPMS ne permet quune relation unidirectionnelle, depuis le BPM vers le SI. Lors de la phase BPI, pour
rendre un processus vraiment excutable, les experts SITI doivent documenter un nombre consquent
dinformations techniques. Il existe un grand nombre de standards en ce qui concerne la modlisation du
processus, la notation graphique, lexcution des processus et les langages associs. Nanmoins, la
phase dimplmentation reste pniblement automatisable et il parat illusoire de croire pouvoir fournir
directement un modle BPA prt tre excut. Pour y remdier, les diteurs BPMS proposent des
architectures souvent opaques et peu modifiables (via des connecteurs spcifiques, comme par exemple
pour ceux fournis pour lERP SAP), loppos de la notion de couplage faible recherch et de lagilit qui
lui est associe.
Lobjectif principal du BPM est damliorer la communication entre acteurs mtier et experts SITI
pour rendre les processus de lentreprise excutables et contrlables. Cependant, toutes modifications
apportes au modle lors de la phase BPI nest pas systmatiquement signales, ou documentes aux
analystes mtier. Il faudrait cet effet dfinir des rgles de collaboration entre matrise douvrage et
matrise duvre, ce qui est dautant plus vrai que le BPM perturbe les frontires habituelles.
6.6 CONCLUSION
La dmarche BPM est une dmarche dingnierie dirige par les processus permettant une gestion
des processus mtier de bout-en-bout. Il permet un dbut de conciliation entre domaine mtier et
domaine SITI. Il accompagne galement le processus mtier dans sa dmarche damlioration continue.
Le BAM rcolte en effet un ensemble de donnes depuis le BPI afin de constituer des mtriques
permettant lvaluation du processus implment. Ces donnes ensuite utilises dans le BPA permettent
de modifier et doptimiser le processus.
Une dmarche BPM rduit les difficults rencontres lors du passage entre la modlisation et
lexcution des processus. En effet, nous avons pu constater que les acteurs mtier sont rticents
sapproprier les formalismes proposs par les experts SITI et autres informaticiens pour spcifier
simplement les processus automatiser. Les formalismes de type UML ou bien les dmarches
durbanisation se sont avrs trs loigns des manires de penser des analystes du mtier. Une
dmarche BPM permet ainsi de sparer la vision mtier (et le formalisme laccompagnant) de la vision
SITI (et le formalisme associ).
Des suites BPM furent dveloppes facilitant la transformation des modles BPA vers des modles
BPI ainsi que leur supervision. En effet, les outils de modlisation seuls utiliss par les acteurs mtier ne
sont pas forcment en mesure dexcuter les processus modliss. Rares sont les logiciels danalyse de

processus utiliss lors de ltape BPA qui vont jusqu linformatisation des processus ou leur excution.
Rien ne garantit que le modle de processus soit informatisable lors de sa gnration dun outil de
modlisation non-intgr un BPMS complet. Ainsi au sein de lentreprise, les modles de processus
restent la plupart du temps purement contemplatifs, dconnects du SI, utiliss seulement comme un
rfrentiel de connaissances (sous MS Visio ou autre outil de bureautique par exemple). Lalignement
mtier-SITI nest ni valid, ni vrifi.
Nous avons nanmoins vu les limites du BPM. Il reste difficile de maintenir un lien entre BPA et
BPI permettant dassurer une cohrence et une synchronisation intermodle. Lutilisation dun BPMS
sinscrit dans une architecture ferme et est ce jour restrictif. Elle va lencontre de notre recherche
dagilit au niveau fonctionnel dune entreprise. La partie suivante mettra en exergue ces difficults dont
la rsolution caractrisera notre approche solution.

TROISIEME PARTIE
C. DEFINITION DE LAPPROCHE
7. De la ncessit de lapproche .. 77
8. Caractrisation .. 89
9. Conception .. 97

76 C. DEFINITION DE LAPPROCHE

RESUME
Nous mettons en avant les dysfonctionnements de lingnierie des processus mtier lors de son
application. Aprs un court exemple utilisant les standards les plus rpandus du BPM, nous discutons
des limites dune dmarche BPM. De ces limites, nous exposons les solutions quapporte notre approche
pivot. Les chapitres suivants dfinissent le champ dapplication de notre approche ainsi que ses
caractristiques. Nous insistons en particulier sur les liens existants entre modles et mtamodles, ainsi
que sur la formation et la constitution du mtamodle pivot, cur de lapproche propose.

7. De la ncessit de lapproche
Dans ce chapitre, nous cherchons dfinir les verrous empchant lalignement oprationnel,
responsables de la cration de lcart mtier-SITI. Nous prsentons les concepts et lments permettant
de rendre cet alignement ralisable et ncessaire lapproche propose.

C
H
A
P
I
T
R
E

7

7.1 VERS UN ALIGNEMENT OPERATIONNEL
Afin dillustrer les diffrents propos de ce chapitre, nous considrons la transformation au niveau
fonctionnel depuis un modle BPMN (Business Process Modelling Notation) vers un modle BPEL
(Business Process Execution Language) (Ouyang et al. 2006), (Hettel 2010). BPMN (OMG 2006) est un
langage de notation graphique reprsentant les processus mtier. Manipul par les analystes mtier
dune entreprise, le BPMN fournit entre autres :
- Des activits, reprsentes par des rectangles arrondis ;
- Des portes logiques permettant de faire converger ou diverger le flux de contrle. Ces portes
sont reprsentes par des losanges ;
- Des vnements identifiant les interactions avec le monde extrieur , reprsents par des
cercles ;
- Un squencement indiquant lordre dexcution, dfini par des flches reliant les lments
voqus prcdemment.
A laide de ces diffrents lments, une squence dactivits dun processus peut tre dtaille afin
de raliser un objectif mtier (comme produire ou vendre des biens). Lutilisation de portes logiques
permet de reprsenter la prise de dcision ou une excution parallle. La Figure 31(a) dcrit un exemple
de modle BPMN.
BPEL dun autre ct est un langage dexcution orient blocs ou bloc-oriented(OASIS 2007). Utilis
par les experts SITI, il ne possde pas de notation graphique et utilise la place une srialisation XML.
La Figure 31(b) reprsente le rsultat dune transformation depuis le modle BPMN prcdemment cit.

A B
(a)

<repeatUntil >
<sequence>
<invoke name="A"/>
<invoke name="B"/>
</sequence>
<condition></condition>
</repeatUntil>

<repeatUntil >
<sequence>
<invoke name="A"
parterLink="LinkA" />
<invoke name="B"
parterLink="LinkB" />
</sequence>
</repeatUntil>

(b)
(c)
Modifications
Transformation
?
Retour possible ?
7. DE LA NECESSITE DE LAPPROCHE 79

Plusieurs changements interviennent lors de cette transformation. Dune part, il faut prciser que
lors de cette transformation, les aspects graphiques du modle BPMN sont perdus. Dautre part, le
modle BPEL obtenu peut ncessiter des ajustements de code. Par exemple, les variables contenues au
sein des activits A et B peuvent ncessiter dtre dclares comme assignes des paramtres de
services-web. Ces informations ncessaires lexcution du processus modlis sont ajoutes et
reprsentes Figure 31(c), ici les partnerLinks .
Suite cette transformation et ces modifications, plusieurs interrogations peuvent nous
interpeller :
- Les modles (a) et (c) sont-ils toujours synchroniss ?
- Les modles (a) et (c) sont-ils smantiquement quivalents ?
- Les modles (a) et (c) sont-ils cohrents entre eux ?
Les sous-sections suivantes tentent de rpondre ces diffrentes questions.
7.1.1 Synchronisation
Les modles (a) et (c) sont-ils toujours synchroniss ?
Nous dfinissons la synchronisation entre modles de la manire suivante :

Dans lexemple propos, les modles ne sont plus synchroniss. Les prcisions apportes la
Figure 31(c) modifient son comportement (ici, la manire dont les diffrentes activits du processus
modlis sont excutes). Cependant, ces modifications ne peuvent pas tre retranscrites dans un
modle BPMN et donc dans le modle (a).

P5 : Synchronisation
La solution envisage doit assurer la propagation des modifications
dun modle un autre afin de maintenir ces modles synchroniss.

7.1.2 Equivalence smantique
Les modles (a) et (c) sont-ils smantiquement quivalents ?
(Izza 2006) dfinit lquivalence ainsi : deux concepts sont quivalents sils ne reprsentent quun
seul et mme concept. Il demeure difficile de comparer lquivalence smantique de modles
Figure 31. Transformation dun modle BPMN un modle BPEL
Deux modles, i et j, sont dits synchroniss si et seulement si des
changements significatifs effectus sur le modle i peuvent tre rpercuts
sur le modle j. Est considr comme significatif tout changement modifiant
la structure et/ou le comportement dun modle.

syntaxiquement diffrents et dabstraction diffrente. Cependant, en sappuyant sur (Izza 2006), nous
pouvons proposer la dfinition suivante :
Considrons les modles i et j et lensemble respectif des lments constituant ces modles, E
i
et
E
j
.

Dans cet exemple simple, les modles restent smantiquement quivalents : le droulement du
processus reste identique, quil sagisse du droulement des activits dans le modle (a) ou dans le
modle (c). Cependant, les modles ntant plus synchroniss, si une modification importante devait
intervenir sur le modle (c), celle-ci ne serait pas rpercute sur le modle (a), le rendant obsolte et
lquivalence entre modle ne serait plus maintenue.

P6 : Equivalence
smantique
Les relations smantiques entre les lments de modles htrognes
doivent tre dtermines laide la plateforme solution.

7.1.3 Cohrence intermodle
Les modles (a) et (c) reprsentent-ils le mme processus ?
Pour les analystes mtier de lentreprise, le processus reprsent par le modle BPEL peut
paratre diffrent de celui dfini selon le langage BPMN. Il peut en effet tre compliqu un analyste
mtier de retrouver un modle BPMN la lecture des lignes de code de ce mme modle modifi et
srialis en XML selon un standard mettant en avant limplmentation des processus. Cependant, les
modles BPMN ou BPEL peuvent exprimer la mme chose. Ainsi, le terme Reprsentation semble ici
inadquat. De ce fait, nous le remplaons par celui de Cohrence intermodle , terme prsent dans
(Ulmer et al. 2010b). Nous supposons quun tel lien existe entre deux modles si :

Nous considrons cette cohrence intermodle comme une condition ncessaire et suffisante dun
alignement oprationnel tel que dfini section 2.2.3. Obtenir un alignement fonctionnel nest pas une
solution triviale en soi, cependant cet alignement est recherch au sein dun cycle BPM. Les sections
suivantes dcrivent pourquoi lalignement mtier-SITI est si important et quelles sont les diffrentes
difficults rencontres.
Les modles i et j sont smantiquement quivalents si:
- Pour chaque lment appartenant E
i
, un lment (ou un
ensemble dlments) appartenant E
j
peut lui tre associ ;
- Chacun de ces lments associs suit la mme orchestration.
Il existe une cohrence dite intermodle entre deux modles si nous
observons une quivalence smantique et sils sont synchroniss entre
eux.

P7 : Cohrence
intermodle
La solution propose doit garantir lobtention dune cohrence
intermodle.
7.2 HETEROGENEITE ET DIFFERENTES ABSTRACTIONS
Un processus mtier est essentiellement considr selon deux visions bien distinctes : une vision
mtier et une vision SITI. Le processus modlis doit tre comprhensible la fois par les acteurs mtier
et les acteurs SITI. En consquence un processus mtier est support par diffrents modles au cours
de son cycle de vie. Nous pouvons essentiellement distinguer deux types de modles : le modle
danalyse et le modle dimplmentation (Figure 32).

7.2.1 Modle danalyse
A travers la vision mtier, nous considrons le processus suivant le point de vue du monde rel
et selon un environnement donn. Dans le sens o nous dsirons reprsenter un ensemble dactivits
ralises au sein dune entreprise, le processus est reprsent laide de termes mtier exprims
gnralement dans un langage naturel. La plupart du temps, il sagit dune reprsentation graphique
facilitant la communication entre acteurs au sein dun projet. Le modle de processus rsultant respecte
des rgles mtier
9
conventionnelles, mais pas forcment formelles.
7.2.2 Modle dimplmentation
A linverse, une vision SITI permet dadopter un point de vue technique. Le processus modlis est
dcrit laide de notions et de termes propres aux SITI. Le modle rsultant est dfini avec prcision

9
Une dfinition des rgles mtier est donne section 7.3.1
Domaine mtier
Domaine SITI
Analyste mtier
Expert SITI
A B

<repeatUntil >
<sequence>
<invokename="A"
<invokename="B"
</sequence>
</repeatUntil>

Modle danalyse
Modle dimplmentation
Figure 32. Domaines, acteurs, modles

selon un contexte donn et respecte normalement les exigences spcifies entre les utilisateurs finaux et
les dveloppeurs. Ce qui permet ce modle dtre correctement implment sur le moteur cible
dexcution de processus.
7.2.3 Deux domaines, deux visions : prmisses de lcart mtier-SITI
Ainsi un modle conceptuel utilisant une charte graphique, comme le propose le standard BPMN,
nest pas utilis par la mme communaut quun modle dimplmentation bloc-oriented reposant sur un
standard comme BPEL. Chacun de ces modles propose ainsi une vision bien distincte.
Nous avons dcrit le modle danalyse comme un modle conceptuel permettant de reprsenter
tout ou partie dun processus de manire comprhensible pour un analyste mtier. Les critres mis en
avant dans ce type de reprsentation sont laspect graphique et la reprsentation des flux. Nous ne
chercherons pas systmatiquement formaliser les diffrents lments du modle selon une logique
technique avre, comme cela est le cas avec un modle dimplmentation.
Ainsi, la reprsentation dun processus selon des critres mtier peut tre imprcise, ambige et
sujette interprtation dun point de vue informatique. Il sagit typiquement dun modle mtier non-
formel utilis des fins de documentations ou de communications entre acteurs. Si par dfinition un
modle nest bien quune abstraction dun systme plus complexe, lorsquun modle mtier nest
interprtable que par lhumain, alors il sagit dun modle contemplatif (Ulmer et al. 2009).
La phase danalyse produit des modles de processus mtier non formels et interprtables
essentiellement par lhomme rendant la phase dimplmentation plus complexe. De ce fait, lorsque le SI
est modifi ou volue, les modles danalyse ne sont plus forcment mis jour. Les modles danalyse
ne sont donc plus en synchronisation avec les modles dimplmentation et le systme les excutant.
Les experts SITI peuvent considrer que le modle dimplmentation obtenu suite une transformation
depuis un modle danalyse prsente des irrgularits et/ou ncessite des modifications. La logique du
processus peut ainsi tre directement modifie au niveau de la phase dimplmentation et non au niveau
de lanalyse : la smantique exprime diffre selon les modles. Et comme la transformation entre phase
danalyse et dimplmentation est le plus souvent unilatrale, le modle danalyse nest jamais modifi en
consquence, au sens de la rtro-ingnierie.
Si lutilisation de deux formalismes amliore la description du processus ainsi que sa
comprhension envers les acteurs de lentreprise le manipulant, il ne contribue nullement amliorer le
dialogue entre diffrents acteurs. Labsence de synchronisation et la non-quivalence smantique entre
modles ne permettent pas dobtenir une cohrence intermodle. Il sagit typiquement du Business-IT
gap rencontr dans la littrature, de lcart existant entre domaine mtier et domaine SITI : le non-
alignement oprationnel.
7.3 CONCEPTS ET APPROCHES POUR UNE GESTION AGILE
A laide de lapproche propose, nous essayons de rduire cet cart mtier-SITI. Lapproche
sappuie sur une plateforme permettant la transformation des modles danalyse vers les modles
dimplmentation et garantissant la cohrence intermodle. Aussi, lapproche propose une gestion plus

agile des processus mtier. Ce rsultat est notamment obtenu grce lutilisation de rgles mtier, la
dfinition dun couplage faible entre modles et lutilisation systmatique de mtamodles afin, entre
autres, de faciliter et formaliser les transformations entre modles.
7.3.1 Utilisation de rgles mtier
Utiliser une approche par rgle mtier permet de saffranchir des problmes dus lhritage
dapplication ou legacy software, dont le code devient au fil du temps difficile maintenir et faire voluer.
Or, nous cherchons obtenir des systmes capables de sadapter rapidement aux changements de
lenvironnement. Le comportement dun systme dinformation doit tre modifiable par lanalyste mtier
sans pour autant quil ait se soucier des contraintes techniques. Selon (Ross 2003) lapproche par
rgles mtier fournit une zone de collaboration entre analystes mtier et experts SITI. Les rgles mtier
sparent la logique mtier (le comportement) de la logique systme dune application (lexcution).
Selon (Hay and Healy 1997), nous dfinissons les rgles mtier de la manire suivante :

Ainsi, avec une approche par rgles mtier, chaque domaine mtier dune application est contrl
et gr par lexpert mtier du domaine (par exemple le banquier pour une application bancaire).
(von Halle 2002) met en avant que si les rgles mtier se situent au cur de toute application, cela
les rend plus difficiles recenser et structurer en une approche de gestion efficace. L'utilisation d'un
systme de gestion de rgles mtier ou Business Rules Management System BRMS, facilite le recensement et
la mise en uvre de ces rgles.

P8 : Comportement
Le modle dun processus mtier possde des informations sur le
comportement des lments structurant ce processus et leur
agencement. Notre solution doit pouvoir reprsenter distinctement ces
deux aspects.

7.3.2 Facilit lvolution des plateformes
Nous avons dclar prcdemment que la principale limite rencontre au sein dun cycle
dingnierie des processus rside dans la discontinuit entre le domaine mtier et le domaine SITI.
Majoritairement, la solution logicielle choisie pour supporter ces transformations est un BPMS (intgr ou
non au SI, type ERP). Il convient de garder lesprit que les modles sont amens tre modifis, les
processus reprsents et les technologies de linformation utilises pouvant voluer. Des efforts de
synchronisation, de mises jour et de cohrence entre modles savrent alors ncessaires. Lentreprise
et donc la nature de ses modles tant en perptuelle volution, elles doivent pouvoir sadapter
diffrents diteurs ou de nouvelles technologies. Cependant lapproche intgre de modlisation base
Une rgle mtier est une formulation qui dfinit ou contraint certains
aspects d'un mtier. Elle permet de structurer, de contrler ou dinfluencer
le comportement du mtier.

sur un atelier logiciel unique comme le BPMS, se traduit par une dpendance forte lditeur.
Lentreprise ne possde plus la possibilit de modifier loutil de modlisation voire la plateforme
dintgration, indpendamment lun de lautre (Figure 33).

De nombreuses solutions type ARIS, IBM-Telelogic issues de larchitecture dentreprise
utilisent des transformations pour passer dun modle danalyse ou modle BPA (Business Process
Analysis) un modle dimplmentation ou modle BPI (Business Process Implementation). Pour
amliorer leur utilisation et leur support, les diffrents lments composant un BPMS (et les mtamodles
sous-jacents lorsquils existent) sont manipuls de faon opaque et propritaire. Il en rsulte une
transformation unilatrale o le modle de processus mtier ne peut ni tre transform sous un autre
langage dexcution ni tre modifi sous un autre diteur. Il est galement difficile de garantir la
conformit entre modles et mtamodles.
Par exemple, ARIS contient plusieurs techniques diffrentes de modlisation de processus mtier.
Chaque aspect du processus modlis est dcrit par un mtamodle. Nanmoins, il ny a pas de
mtamodle global assurant la cohrence entre ces mtamodles (Leist and Zellner 2006). Il existe
nanmoins une DTD - Document Type Definition - du modle global dARIS utilisable pour manipuler les
exportations XML de ARIS, tous modles confondus. Cependant, si une DTD dfinit bien une grammaire
pour une classe de documents, elle ne permet pas dexprimer clairement le vocabulaire et les rgles
utiliss au sein dun modle. Il peut ainsi se rvler insuffisant pour dcrire lensemble des informations
contenues dans un modle.
Ceci conduit la volont dobtenir un couplage faible entre le modle issu du BPA et le modle
issu du BPI. Ici, la notion de couplage faible dsigne le fait que bien quil existe une interaction forte, ces
modles demeurent autonomes et les environnements associs restent modifiables.
Environnement de modlisation
Environnement dimplmentation
Analyste mtier
Expert SITI
A B

<repeatUntil >
<sequence>
<invokename="A"
<invokename="B"
</sequence>
</repeatUntil>

Modle danalyse
Modle dimplmentation
Figure 33. Eviter le couplage fort du BPMS

P9 : Couplage faible
Corollaire des proprits P2 et P4, notre plateforme solution doit
supporter ce couplage faible entre les outils des diffrents
environnements.
7.3.3 Transformation entre modles : la ncessit du mtamodle
Selon lenvironnement dans lequel un modle est dfini, il obit un langage dexpression et des
rgles structurelles. Ce langage et ces rgles peuvent tre formaliss sous la forme dun mtamodle.
Ainsi, les environnements de modlisation et dimplmentation peuvent avoir chacun un mtamodle.
Nous dsignons le mtamodle issu de lenvironnement de modlisation comme tant le mtamodle
BPA. Nous procdons de faon identique avec le mtamodle issu de lenvironnement dimplmentation,
dsign comme tant le mtamodle BPI. Ces diffrents mtamodles dtaillent chacun des aspects
diffrents dun mme processus ; considrer leurs relations peut savrer ncessaire et permet davoir
une vue plus complte du modle de processus (Saidani et Nurcan, 2008).
La mise en correspondance de ces mtamodles se ralise selon un mtier particulier. Ceci
implique une prise en compte structurelle et smantique des processus modliss. Cependant lors dune
approche BPM, les mtamodles BPA et BPI ne sont pas toujours explicites et formaliss. Les rgles de
transformation entre modles BPA et BPI sont alors peu flexibles car dfinies au cas par cas.
Un des aspects important de lIngnierie Dirige par les Modles (IDM) est la transformation de
modles. Nous considrons que, de manire gnrale, la transformation de modles utilise un ensemble
dapplications prenant en entre des modles accompagns de leur mtamodle et produisant en sortie
dautres modles. La Figure 34 reprsente cette transformation de modles selon lIDM.

Un large panel doutils a t dvelopp afin de dfinir ces transformations. Ce panel peut tre
divis selon quatre catgories (Faucher et al. 2008) :
Modle dentre
Mtamodle dentre
Mtamodle de
transformation
Programme de
transformation de modle
Modle de sortie
Mtamodle de sortie
Mta-mtamodle
conformeA
Figure 34. Transformation de modles selon IDM

- Outils de transformations gnriques comportant, entre autres, des outils appartenant
lespace technique XML comme XSLT ou XML Query . Les langages utiliss par ces outils ne
permettent pas de travailler la smantique des modles.
- Langages de script intgrs des ateliers de gnie logiciel comme par exemple le langage J
de latelier Objecteering . La limite principale de ces langages est quils sont essentiellement
propritaires, penss comme des langages utilitaires et non des langages de transformation.
- Outils ddis spcifiquement la transformation de modles et normalement conus pour
tre intgrables dans des environnements de dveloppement normaliss, comme le langage Atlas
Transformation Language - ATL (Bzivin & Blanc 2002) par exemple;
- Outils de mtamodlisation o la transformation de modles correspond lexcution dun
mtaprogramme. Un mtaprogramme est en mesure de manipuler les modles et mtamodles
dentres et de sorties grce la rflexivit du langage. La transformation est alors implmente
en ajoutant aux parties structurelles des comportements grce un langage daction. Le langage
Kermeta (Muller et al. 2005) en est un exemple.
Les deux dernires catgories cites permettent de disposer pleinement de langages de
transformations laide dune syntaxe oriente modle et non objet.
7.4 CONCLUSION
Les transformations des modles selon un cycle dingnierie des processus restent compliques
mettre en uvre malgr laide doutils comme les BPMS. Ces derniers mettent les dirigeants dune
entreprise en face dun choix tout aussi compliqu : agilit ou alignement oprationnel ?

Rtro-ingnierie
possible ?
Figure 35. Une bonne architecture BPM (Havey and Havey 2005)

En effet, lutilisation dun BPMS a pour consquence de faciliter les transformations depuis la
phase danalyse, BPA, vers la phase dimplmentation, BPI. Un alignement temporaire entre modles
danalyse et modles dimplmentation peut tre obtenu. Afin dimplmenter correctement les processus,
leurs modles sont modifis lors de la phase BPI. Ces modifications ne sont pas rpercutes sur les
modles danalyse associs, la synchronisation nest pas maintenue. Il ny a plus de cohrence
intermodle et donc plus dalignement oprationnel comme nous lavons dfini. La transformation reste
unilatrale. Toutes modifications apportes au processus un niveau BPA entrane une nouvelle
gnration complte dun modle. Les diffrentes expertises apportes au modle lors de la phase BPI
sont ritrer. En considrant la bonne architecture BPM propose par (Havey & Havey 2005)
(Figure 35), nous remarquons quil ny a pas de retour dinformation vers les modles BPA modliss en
amont. Si ces modles ne sont pas enrichis et mis jour, alors ils risquent de devenir terme des
modles contemplatifs , des fichiers documentaires difficilement exploitables et dsynchroniss des
modles BPI et donc des processus mtier excuts.

P10 : Transformation
La transformation entre modles doit tre bilatrale et formalise
laide doutils de mtamodlisation.
Afin de pallier ces dficits, nous proposons une approche se basant sur lutilisation dun modle
intermdiaire, un modle pivot. Cette approche assurerait un couplage faible entre BPA et BPI et la
cohrence entre les diffrents modles et mtamodles.
Dans les chapitres suivants, nous prsentons cette approche. Nous dmontrons comment
lutilisation dun lment pivot au sein dun cycle permet dobtenir un alignement entre modles et
environnements htrognes. Nous montrons comment les diffrents concepts et approches lis
lagilit des processus y sont employs. Notre approche est ensuite mise en uvre par une plateforme
dcrite partie D, nomme Solution pour un ALignement et une Cohrence entre Processus, SCALP.
Lapproche et la plateforme associe sont en mesure de garantir un meilleur alignement oprationnel
entre domaine mtier et SITI via une cohrence intermodle telle que dfini paragraphe 7.1.3 et une
gestion plus agile des processus.

8. Caractrisation
Aprs avoir expos les difficults raliser un cycle dingnierie des processus et du non-
alignement qui se cre entre domaine mtier et domaine SITI un niveau oprationnel, nous dfinissons
notre approche et expliquons comment elle parvient amliorer cet alignement, tout en permettant une
gestion agile des processus.

C
H
A
P
I
T
R
E

8

8.1 VERS UNE APPROCHE CENTREE PIVOT
Le rle du pivot est dassurer une quivalence smantique entre un modle analyse et le modle
dimplmentation lui correspondant.
A travers nos diffrents travaux (Ulmer et al. 2009), (Ulmer et al. 2010a), nous proposons une
mthode centre pivot afin damliorer lalignement des diffrents modles issus des phases danalyse
(BPA) et dimplmentation (BPI). Lalignement parfait tel que dfini par (Etien 2006) peut tre obtenu par
lutilisation dun pivot. Le concept de pivot a dj t utilis selon divers niveaux dabstraction.
Pour limplmentation des transformations de ses modles, le projet FAROS
10
(Blay-Fornarino et
al. 2008) utilise cette notion de pivot. Il sagit ici de transposer des lments mtier, des contrats, au sein
de plateformes techniques. Lutilisation dun modle et dun mtamodle pivot permet de formaliser ces
transformations depuis la matrise douvrage vers la maitrise duvre et de les rendre reproductibles.
Nous pouvons galement citer les travaux de (Thevenet 2010) et de la mthode INSTAL ( INstal
Strategic ALignment ). Cette mthode sintresse aux intentions dalignement partages par les deux
niveaux aligner (stratgique et oprationnel) et qui reprsente ici lalignement stratgique.
A un niveau dabstraction infrieur, nous pouvons considrer, par exemple, les systmes de
gestion de base de donnes (SGBD) notamment pour les bases de donnes relationnelles et la mthode
MERISE (Baptiste 2009). Lutilisation de modles diffrents dans les bases de donnes composantes
pose des problmes dhtrognit syntaxique. Une solution possible est de traduire tous ces schmas
en un modle commun, le modle pivot, nomm le modle logique de donnes.
Le concept de pivot nest pas non plus inconnu au sein du domaine mtier du Process Systems
Engineering (PSE). Le rapide dveloppement doutils dingnierie des procds assiste par ordinateur a
entran le dveloppement du standard CAPE-OPEN (Belaud 2002). CAPE-OPEN a pour rle daccrotre
linteroprabilit entre outils logiciels PSE. Tel un pivot de bas niveau, CAPE-OPEN permet, via son
middleware, des logiciels htrognes dditeurs diffrents dinteroprer, indpendamment de leurs
langages de programmation et de leur systme oprant.
A travers lapproche propose dans ce manuscrit, nous considrons que le systme pivot doit tre
en mesure de faciliter la transformation entre des modles de perspectives et dabstractions diffrentes. Il
doit pouvoir ajouter les informations ncessaires, prserver lintgrit de ces informations et leur
cohrence. Il doit permettre une indpendance entre lenvironnement de modlisation et lenvironnement
dimplmentation afin dassurer un couplage faible entre modles issus de ces environnements. Ce
format intermdiaire devient alors ncessaire pour stocker et changer les informations des modles
entre les environnements de modlisation et dimplmentation. Notre approche se veut holistique. Il faut
identifier tous les aspects dcrivant un systme afin de mieux le dfinir, ce qui dans notre cas revient
dfinir les activits excuter, les documents ncessaires leur excution, les agents impliqus et les
ressources utilises.

10
Projet ANR RNTL FAROS (composition de contrats pour la Fiabilit dArchitectures Orientes Services) : http://www.lifl.fr/faros
8. CARACTERISATION 91

Cependant, bien que nous dsirions adopter une approche holistique et gnrique, cette globalit
et cette gnricit sont dpendantes dun domaine mtier particulier. Dans les sections suivantes, nous
tablissons la couverture de notre approche et les acteurs ncessaires sa ralisation. Ce chapitre se
conclut par de brefs exemples dapproches utilisant cette notion de pivot.
8.2 VUES
Les perspectives, ou vues, utilises par les processus manipuls, dfinissent la vision globale de
notre approche. Un processus peut tre peru selon les diffrentes vues dune entreprise. Chacune de
ces vues permet de dcrire un aspect important des modles de processus :
- La vue fonctionnelle dcrit les processus et leurs structures. Chacun des processus peut
tre dcompos en sous-processus ;
- La vue informationnelle dcrit les donnes et les documents quun processus utilise ou
produit. Ainsi les donnes entres et sorties dun processus sont dcrites. Toutes ces entres et
sorties construisent ensemble le data flowdu modle de processus ;
- La vue organisationnelle dfinit les acteurs et les rles qui sont responsables de lexcution
dun processus donn ;
- La vue des ressources (ou vue oprationnel) dfinit les outils et les systmes qui supportent
lexcution du processus
- La vue comportementale dcrit lordre dans lesquels les processus sont excuts, le control-
flow.
Vu dans la section 3.4.2, la vue fonctionnelle est au cur des autres vues de lentreprise et est
connecte toutes ces autres vues par lintermdiaire de llment Activit. Nos modles danalyses
reposeront essentiellement sur une vue fonctionnelle (Figure 36). Nanmoins les concepts inhrents aux
autres vues peuvent intervenir de manire ponctuelle, en fonction des standards et langages de
modlisations utiliss.

Considrons par exemple BPMN, un langage standard de modlisation de processus dentreprise,
il est centr sur la vue fonctionnelle, mais il permet de reprsenter les documents mis ou reus (vue
informationnelle) et de dfinir des actions intervenant au sein des rseaux de circulation des
produits/information (vue des ressources). Notre approche se focalise essentiellement sur la vue
Vue des
ressources
Vue
fonctionnelle
Vue
informationnelle
Vue
organisationnelle

Espace des modles dentreprises
Couverture du
modle danalyse
Figure 36. Modles danalyse et espaces des modles dentreprises (daprs (Touzi 2007)

fonctionnelle et est centre en particulier sur la notion dactivit/processus, telle que perue par (Vernadat
1999).
8.3 GENERICITE
La gnricit prne par notre approche nest pas absolue. Une gnricit absolue signifierait que
notre pivot est capable de sadapter tous types de modles, issus de langages standards ou
spcifiques. Cet objectif peu ralisable rendrait notre mtamodle pivot complexe, difficile mettre en
uvre et maintenir. Il faut chercher un compromis entre gnricit absolue et simplicit/agilit. La
gnricit, telle que considre dans ce manuscrit, se veut gnrique selon un contexte donn et un
domaine mtier spcifique. Cette gnricit est alors considre comme tant relative . Ainsi notre
pivot est relatif un domaine mtier (services bancaires, procds physico-chimiques), un contexte
dtude et au niveau dabstraction recherch. Nanmoins lapproche oriente pivot propose ici demeure
elle-mme gnrique et indpendante du mtier et des technologies employes.
8.4 ACTEURS
Nous pouvons facilement identifier les deux acteurs ncessaires laccomplissement dun cycle
BPM, lanalyste mtier et lexpert SITI. Un analyste mtier recherche de nouvelles faons damliorer
lefficacit mtier de son entreprise (Various IIBA & Brennan 2008). Cette amlioration peut tre
ralise en modifiant la manire de travailler collectivement, en changeant doutils ou de processus.
Lexpert SITI prend en charge ces besoins mtier et les transforme selon des considrations techniques.
A lissue des problmes exposs dans le chapitre 7, nous avons montr quil est ncessaire dadopter
une approche holistique et donc davoir une vue multi-perspective complte et globale de la mthodologie
BPM. Ainsi un troisime acteur se rvle ncessaire, que nous nommons architecte des processus
mtier. En conciliant les deux niveaux dabstractions propres lanalyste mtier et lexpert SITI, lacteur
pivot permet de fluidifier les changes et dobtenir une meilleure cohrence entre modles. Il joue
le rle dinterface. Il possde les connaissances ncessaires mtiers et techniques pour dfinir un style
architectural . Ces diffrents acteurs sont reprsents sur la Figure 37.
8.5 DONNEES
Concrtement le rle de larchitecte des processus est de dterminer quelles sont les donnes
provenant dun modle danalyse et utilises par un modle dimplmentation associ (a), comme par
exemple les donnes relatives au control-flow.
Larchitecte des processus doit garantir la prservation de lintgrit des informations depuis le
modle danalyse vers le modle dimplmentation rsultant (b). Il peut sagir dinformations graphiques,
des annotations non-spcifiques ou non ncessaires pour le modle dimplmentation.
Il doit galement tre capable dapporter des informations ncessaires la bonne formation du
modle dimplmentation (c), par exemple des dtails sur les rles et les mthodes. Ces donnes ont
ce stade une valeur par dfaut. Elles sont amenes tre modifies en consquence par lexpert SITI.
De ce fait, les donnes ainsi modifies deviendront, lors de la transformation retour, soit des donnes

utilisables par lanalyste mtier (a), soit des donnes non-utilisables (b), reprsentes par des flches en
pointilles sur la Figure 37.
Lopration inverse (transformation dun modle dimplmentation vers un modle danalyse)
seffectue de la mme manire et ncessite la mme participation de la part de larchitecte des
processus. En effet, larchitecte des processus est responsable de la stratgie technique de lorganisation
et il doit conserver une vision globale et complte de la mthodologie BPM employe.
La Figure 38 montre en dtail comment ltape pivot fournit les donnes additionnelles contenant
des informations de type (c), travers un cycle BPM. La figure met en avant les deux cas de
transformations rencontrs dans notre approche oriente pivot :
- Premire transformation : le modle pivot permet de stocker des donnes qui sont propres
au modle dentre et non utilisables par le modle de sortie. Il fournit galement des donnes
utilisables par le modle de sortie et possdant des valeurs par dfaut. Ces donnes sont ensuite
manipules par lacteur adquat.
- Seconde transformation : le modle pivot est en mesure de stocker des donnes qui sont
propres au modle dentre et de restituer les donnes stockes lors de la premire
transformation. Le modle de sortie obtenu possde ainsi lensemble de donnes ncessaires.

Environnement
dimplmentation
Expert SITI
Environnement
de modlisation
Analyste mtier
Environnement
de modlisation
Environnement
dimplmentation
Environnement
pivot
Expert SITI Analyste mtier
(a)
(c)
(b)
(a) (a)
(b)
(c)
(b)
Modle
danalyse
Modle
dimplmentation
donnes non considres
donnes utilises
donnes cres
A
p
p
r
o
c
h
e

c
l
a
s
s
i
q
u
e

A
p
p
r
o
c
h
e

p
r
o
p
o
s
e

Modle
danalyse
Modle
dimplmentation
Environnement
pivot
Architecte des processus
(a) (a)
(c)
(b)
(b)
Modle
danalyse
Modle
dimplmentation
Figure 37. Rles et donnes

Lgende - Donnes:
Spcifiques au modle dimplmentation
(par dfaut/modifies)
Spcifiques au modle danalyse
(par dfaut/modifies)

Utiles
/
/
Modle
danalyse
+
Modle
dimplmentation
Donnes
additionnelles
Modle
dimplmentation
Modle
danalyse
+
Modle
danalyse
Modle
dimplmentatio
n
+
+
Donnes
additionnelles
Donnes
additionnelles
Donnes
additionnelles
Modle
dimplmentation
+
Donnes
additionnelles
Modle
danalyse
+
Donnes
additionnelles
Modle pivot
Modle pivot
Modle pivot
Modle pivot
B
P
A

B
P
I

Premire transformation utilisant lapproche pivot
B
P
I

B
P
A

B
P
A

B
P
I

B
P
I

B
P
A

Seconde transformation utilisant lapproche pivot
Figure 38. De lanalyse limplmentation laide dun pivot

8.6 CONCLUSION
Essentiellement base sur la vue fonctionnelle, lapproche propose se veut gnrique en restant
indpendante des langages et des environnements. Nous allons voir quelle peut reposer sur lutilisation
de langages spcifiques ou standardiss, langages auxquels nous appliquons des rgles de conformits
et dquivalence smantique afin dassurer une cohrence intermodle ainsi quune transformation
bidirectionnelle entre BPA et BPI. Lobjectif est dobtenir des modles smantiquement forts, indpendant
des environnements de modlisation et dintgration.

9. Conception
Ici, nous mettons en exergue les efforts de formalisation quaccompagne lapproche oriente pivot
que nous proposons. Nous dfinissons formellement les liens existant entre modles danalyse et
dimplmentation, leurs mtamodles respectifs et le mtamodle pivot. Les lments constituant ce
dernier sont prsents et justifis.

C
H
A
P
I
T
R
E

9

9.1 CONFORMITE ENTRE MODELE ET METAMODELE
Afin de pouvoir expliquer les relations entre modles et mtamodles, nous utilisons des concepts
propres lIDM. Nous reprenons ici les exemples proposs par (Favre, Estublier, & Blay-Fornarino
2006).
9.1.1 Modle et ReprsentationDe ()
Considrons un modle comme tant une reprsentation simplifie cre partir dun systme et
selon un objectif bien tabli (Bzivin & Blanc 2002), (OMG 2007a). La relation existante entre le modle
et le systme tudi peut tre reprsente par la relation reprsentationDe, symbolise par Figure 39.

Il faut noter que si la relation est prsente deux fois, le modle dun modle nest pas
systmatiquement un mtamodle.
9.1.2 Mtamodle et EstConformeA ( )
Un mtamodle est dfini comme tant un modle de spcification dun ensemble de modles,
menant lidentification dune relation ConformeA. Par exemple, la Figure 40 reprsente une carte
schmatisant la France, en particulier ses dmarcations avec les pays limitrophes, entre rgions, et ses
routes. Ces trois lments sont dfinis laide dune lgende. Ainsi la carte reprsente est conforme
la lgende, qui peut ainsi tre considr comme le mtamodle (ici extrmement simpliste) du modle
carte.

Afin de dcrire les relations existantes entre modles et mtamodles, nous utilisons les notations
suivantes (Tableau 2. Notations).
Lors dune approche BPM, les mtamodles BPA et BPI ne sont pas toujours explicites et
formaliss rendant notamment les rgles de transformation entre modles BPA et BPI peu flexibles. Afin
<MAP name = France
Taille = 20x20 >
<Region>
<departement>38
</departement>

Modle
Systme
modlis
Figure 39. Relation ReprsentationDe
: Routes
: Rgions
: Pays

Lgende
Figure 40. Relation EstConformeA
9. CONCEPTION 99

dy remdier, nous dfinissons systmatiquement et formellement nos mtamodles danalyse et
dimplmentation, soit respectivement MM
BPA
et MM
BPI
.
Tableau 2. Notations
Symbole Description
MMi Mtamodle i
mi Modle i

Relation EstEquivalentA
L(MMi) Ensemble des modles mi conformes au mtamodle MMi
Relation ReprsentationDe ,
ici considre dans sa version raffine Spcifie

Relation EstConformeA .

Relation APourImage
REMARQUE : LANGAGE DE MODELISATION ET LANGAGE DE PROGRAMMATION
La distinction entre ces langages seffectue entre autres au niveau de leur abstraction. Un langage de modlisation a
un niveau dabstraction plus lev que celui dun langage de programmation. Dans la suite du manuscrit, ces
langages seront traits indiffremment de leur type (modlisation ou programmation).

Chaque mtamodle est dfini selon deux lments. Tout dabord, nous considrons que les
mtamodles sont constitus dun standard, ou langage, de reprsentation not MM
Rep
. Cette notation
peut tre textuelle, graphique ou mixte. Pour lenvironnement de modlisation, MM
Rep
est fortiori
graphique pour rester le plus comprhensible possible vis--vis des utilisateurs mtier.
Le deuxime lment dfinissant le mtamodle reprsente sa smantique. Elle dfinit la manire
dont les concepts de MM
Rep
doivent tre interprts. La smantique peut tre exprime sous plusieurs
formes comme par exemple du texte en langage naturel, des dfinitions mathmatiques, des
spcifications dans un langage informatique. Elle peut galement tre classe selon diffrents types
comme dnotationnelle, imprative, etc. Nous considrons ce deuxime lment comme tant un
ensemble de rgles mtier, dfinissant un rfrentiel mtier que nous notons RefMet. Ce rfrentiel peut
tre obtenu selon des contraintes et/ou rgles mtier comme OCL (Object Constraint Language) pour
UML et SBVR (Semantic Business Vocabulary Rules) pour le BPMN.
Si nous reprenons les relations dtermines dans la section prcdente, le MM
BPA
est spcifi de
la manire suivante () :
HH
Rcp
HH
BPA
(1)
RcHct HH
BPA
(2)
De la mme manire, le modle BPA (not m
BPA
) se doit dtre conforme ( ) MM
Rep
et RefMet.
En effet, le modle BPA doit respecter la fois le langage de modlisation utilis ainsi que les rgles
mtier. Nous dduisons alors la relation suivante :
m
A
HH
BPA
(3)

Cette relation est indique en pointills (Figure 41).

Nous pouvons expliciter par analogie les diffrents liens existant entre le modle BPI not m
BPI
, et
MM
BPI
via leur propre MM
Rep
et RefMet (Figure 42).

Dans la section suivante, nous cherchons dfinir explicitement la notion de pivot et les relations
pouvant exister entre les modles et leurs mtamodles et les lments drivant de cette notion de pivot.
9.2 DE LA TRANSFORMATION DE MODELES BIDIRECTIONNELLES A LA NOTION DE PIVOT
La transformation bidirectionnelle entre modles permet de justifier mathmatiquement la
consistance entre eux. Ds lors, ces deux modles seraient considrs comme tant quivalents et
tablissant une cohrence intermodle.
9.2.1 Relation bidirectionnelle
Considrons MM
A
et MM
B
, mtamodles respectifs des modles m
A
et du modle m
B
. Une relation
dquivalence peut exister entre mtamodles si :
- Avec m
A
HH
A
ct m
B
HH
B

I(HH
A
) =I(HH
B
) (4)
Autrement dit, lespace des modles conforme MM
A
est identique celui de MM
B
.
MMBPA
mBPA
RefMet
MMRep

EstComposDe

Figure 41. Relation entre m
BPA
et MM
BPA

MMBPI mBPI
RefMet
MMRep

EstComposDe

Figure 42. Relation entre m
BPI
et MM
BPI

9. CONCEPTION 101

La transformation bidirectionnelle f permettant dobtenir cette quivalence est dordre bijectif :
- HH
A
HH
B
ct
-1
HH
B
HH
A

Nous obtenons :
m
A
HH
A
,!m
B
HH
B
,(m
A
) =m
B
,
-1
(m
B
) =m
A
(5)
Ainsi pour chaque modle m
A
conforme son mtamodle MM
A
, il existe un unique modle m
B

conforme MM
B
tel que f transforme m
A
en m
B
et inversement.
Nanmoins cette transformation est trop restrictive et devient impossible dterminer si les
cardinalits entre modles sont diffrentes (Stevens 2008). Hors, nous avons vu que nous considrons
des modles qui peuvent tre htrognes et de niveaux dabstraction diffrents. Il peut avoir des
informations dans chaque modle qui ne sont pas contenues dans les autres, en particulier entre
modles appartenant des domaines diffrents, le domaine mtier et le domaine des systmes et des
technologies de linformation.
Une approche possible est de prendre un de ces modles et le transformer de manire ce quil
puisse contenir lensemble des lments, concepts et informations des modles et al. 2009). Soient
A
et
B
deux transformations et MM
Int
un mtamodle intermdiaire :
-
A
HH
A
HH
Int

A
(m
A
) = m
A
i
(6)
-
B
HH
B
HH
Int

B
(m
B
) = m
B
i
(7)
Les modles m
A
et m
B
sont considrs comme quivalent si et seulement si :
m
A
i
m
B
i
(8)
Donc, en considrant que HH
A
HH
Int
et HH
B
HH
Int
, nous obtenons la relation suivante :
m
A

:
A
m
A
i
m
B
i

:
B
m
B
(9)
La transformation bijective peut donc tre rendue surjective, sans pour autant modifier lapparence
des modles perue par lutilisateur, m
A
et m
B
restant inchangs. Notre approche pivot intervient au
niveau de cette nouvelle quivalence.
Notre approche dfinit ces transformations
A
et
B
comme tant des fonctions de conformit
constructive, le modle construit suite ces transformations tant le modle pivot.
9.2.2 Fonctions de conformit constructive
Ces rgles de transformations permettent de passer dun modle m

(i pour BPA ou BPI) un
modle pivot (not m
pot
). Son rle est dassurer une quivalence smantique entre un modle m
BPA


avec un modle m
BPI
. Il doit galement permettre une indpendance entre modle cible et modle de
dpart (modifier m
BPA
sans se soucier du domaine SITI et de lenvironnement dimplmentation associ
ou modifier m
BPI
sans se soucier du domaine mtier et de son environnement danalyse) et ainsi
dobtenir un couplage faible entre m
BPA
et m
BPI
tel que prsent section 6.4.5. Ce format intermdiaire
devient alors ncessaire pour stocker et changer les informations des modles entre les
environnements de modlisation et dintgration.
Afin de garantir la cohrence des modles lors de ces transformations, nous tablissons des
fonctions de conformit constructive (Favre, Estublier, & Blay-Fornarino 2006) c
BPA
et c
BPI
dfinies
respectivement de HH
BPA
et de HH
BPI
vers HH
pot
.
Par dfinition, une fonction de conformit constructive dfinit les deux fonctionnalits suivantes :
- fonction de conformit : dfinit un ensemble doprations, conforme, tel que :
m
L(HH
) si conormc(m
)est vraie (10)

- fonction de conformit constructive : dfinit une relation dquivalence entre modles
selon leurs mtamodles :
Soit m
BPA
I(HH
BPA
) et m
BPI
I(HH
BPI
), alors :

m
BPA

S
= m
BPI
c
BPA
(m
BPA
) c
BPI
(m
BPI
)
(11)
Le s signifie la relation est considre dun point de vue smantique. Cette typologie est dtaille
section Figure 43. Ces fonctions de conformit constructives nous permettent dobtenir le modle pivot :
m
pot
I(HH
pot
),c
(m
) = m
pot
(12)
Avec i pour BPA ou BPI.
Grce ces fonctions, nous dduisons le lien permettant pour passer de lenvironnement de
modlisation celui dimplmentation selon leurs modles respectifs m
BPA
et m
BPI
, considrs comme
smantiquement quivalents. La Figure 43 positionne les diffrents modles, mtamodles et les
relations les liant. Ainsi si nous reprenons la relation 9 et utilisons les lments voqus dans ce
paragraphe, nous obtenons bien le modle pivot comme lment central et ncessaire permettant
lquivalence smantique entre modles danalyse et dimplmentation:

m
BPA
]c
BPA
--m
pot

]c
BPI
-- m
B

(13)
Il convient de noter que si c
(m
) = m
pot
avec m
I(HH
) et m
pot
I(HH
pot
), il nen
demeure pas moins que HH
HH
pot
. En effet, nous avons vu que chacun de ces mtamodles
utilisent des vues et considrent des aspects diffrents du processus.
9. CONCEPTION 103

9.3 TRANSFORMATIONS HORIZONTALES, TRANSFORMATIONS VERTICALES ET INTEROPERABILITE
Les approches MDA et BPM considrent un ensemble de niveaux dabstraction pour leurs modles
de processus. Des transformations soprant sur ces modles peuvent en modifier labstraction pour les
raffiner (modle BPA modle BPI) ou pour les rendre plus abstraits (rtro-ingnierie). Ces
transformations sont dites verticales et nous avons situ notre pivot au sein de cette transformation dans
la section prcdente (modle BPA modle pivot modle BPI).
Il existe galement des transformations dites horizontales. Celles-ci ne modifient pas le niveau
dabstraction dun modle. Elles sont utilises pour restructurer ou complter un modle. Afin dtre
indpendante des environnements de modlisation et dimplmentation, notre approche considre
galement ce type de transformation. En effet, si lanalyste mtier dsire changer denvironnement de
modlisation, il opre une srie de transformations horizontales sur ces modles de processus afin de
passer dun environnement de modlisation A vers un environnement A (Figure 44).
(Grangel et al. 2007) ont par exemple propos un cadre de transformation permettant de
transformer un modle dentreprise dfini en langage GRAI en un modle dactivit UML de mme niveau
dabstraction CIM ( Computational Independent Model ).

MMBPA
mBPA
mBPI
MMBPI MMpivot
quivalent
mpivot
quivalent quivalent

relations [9]
relation [8]
relation [3]
relation [3]
relation [3]
RefMet MMRep RefMet MMRep RefMet MMRep
p
relations [1] [2]
p
relations [1] [2]
p
relations [1] [2]
relations [9]
Figure 43. Modles, Mtamodles, Mtamodle Pivot

Pour obtenir cette interoprabilit, il faut considrer ces transformations entre modles mais
galement lalignement smantique entre environnements. Diffrents travaux de recherche (Panetto et al.
2004) ; (Dassiti 2006) se penchent sur les possibilits dchanger de manire transparente des donnes
et modles un niveau smantique. Par exemple, les concepts MDA ont t tendus afin de grer les
problmes dinteroprabilit. Ainsi le projet ATHENA
11
propose un cadre dinteroprabilit orient
modles ou Model-Driven Interoperability, - MDI et utilise une approche semblable MDA.
Ces considrations sur linteroprabilit des modles de processus sont plus particulirement
tudies au sein du rseau InterOP-VLab
12
. Il prconise entre autre lemploi dUEML (Unified Enterprise
Modelling Language) (Anaya et al. 2008). UEML est un langage de modlisation conu pour faciliter
lintgration de diffrents langages de modlisation dentreprises. A linverse de notre approche o notre
pivot adopte une gnricit relative , UEML adopte un aspect unificateur, reprsentant plusieurs
langages de modlisation du niveau organisationnel de lentreprise. Il est cet effet reconnu comme
lunificateur smantique de langages de modlisation comme GRAI, IEM et EEML. Ainsi, selon (Panetto
2007), linteroprabilit offerte par UEML se situe essentiellement entre les CIM et PIM. A travers notre
approche nous cherchons atteindre une interoprabilit verticale approfondie, entre le PIM ( Platform
Independent Model ) et le PSM ( Platform Specific Model ), autrement dit, entre modles BPA et BPI.
UEML est utilis pour son aspect unificateur et est prsent en dtail dans le manuscrit de thse de
(Bana 2006).
9.4 METAMODELE ET METAMODELES PIVOT
Des efforts de standardisation ont t raliss autour de la standardisation du workflow. (Zur
Muehlen 2004) constate lvolution reprsente Tableau 3.
Tableau 3. Evolution de la standardisation du workflow
Anne 1994 2004
Groupe de standardisation montrant un intrt pour le
workflow
1 Plus de 10
Type de standards
1 modle de rfrence +5
interfaces standards
Plus de 7 standards seulement pour
les modles de processus
Taille moyenne des spcifications Environ 40 pages Plus de 100 pages

11. http://www.modelbased.net/mdi/index.html
12. http://interop-vlab.eu/
Modle BPA Modle Pivot Modle BPA
Environnement de
modlisation A
Environnement de
modlisation A
Transformations
Figure 44. Environnements de modlisation et transformations horizontales
9. CONCEPTION 105

La classification propose par (Hollingsworth 2004) montre quel point le nombre de standards
sintressant plus particulirement au BPM est lev.
Nous cherchons dfinir quels sont les standards typiques et les plus reprsentatifs du cycle BPM.
Ils nous serviront ensuite dcrire les diffrents lments constituant notre mtamodle pivot.

Des efforts dvaluations de langages de modlisation (List and Korherr 2006), de caractrisation
de telles approches (Roser and Bauer 2005) ou encore la comparaison de ces langages et standards
(Mendling et al. 2004) nous indiquent lesquels sont adquats notre approche (Tableau 4).
Tableau 4. Rcapitulatifs des standards
Langages de modlisation Standards Pivot Langages dexcution
UML AD, EPC, BPMN BPDM, XPDL BPEL, ebXML BPSS

Notre choix sest port sur BPMN, BPEL et XPDL, standards les plus reprsentatifs de leur
catgorie selon (Zur Muehlen 2008). Nous allons en donner une brve description.
BPMN (Business Process Modelling Notation) est dvelopp par lOMG
13
(Object Management
Group). BPMN fournit une notation graphique qui cible en premier lieu les analystes domaine et est
support par plus de cinquante outils de modlisation. Trs souple, BPMN est un langage dans lequel les
nuds daction et de contrle peuvent tre connects presque arbitrairement (Ouyang, Van der Aalst,
Dumas, & Ter Hofstede 2006). Dans la forme prsente dans (OMG 2008), BPMN 1.2 nest pas encore

13
Voir www.bpmn.org
Figure 45. Classification des standards lis BPM selon (Hollingsworth 2004)

capable de capturer tous les dtails ncessaires un traitement automatis dun modle de processus
au sein dun moteur dexcution BPM. Il lui manque la prcision smantique ncessaire lui permettant de
capturer des processus mtier implments. Une transformation depuis un modle BPMN vers un
langage excutable devient alors ncessaire.
Dvelopp dans ce sens, BPEL (Business Process Execution Language for Web Services) est un
langage dexcution dfinissant les processus complexes comme tant une composition de services web
dvelopp par OASIS
14
. BPEL 2.0 est essentiellement structur en blocs et support par plusieurs
plateformes dexcution, il cible les dveloppeurs logiciels. Dans ltat actuel, traduire des modles
BPMN en code est une tape ncessaire au regard dun environnement de dveloppement de processus
mtier bass sur les standards. Cette tape est dautant plus complique car BPMN et BPEL
reprsentent deux classes de langages diffrentes. La transformation BPEL-BPMN ne pose pas de
relles difficults, la plupart des activits BPEL peuvent tre transformes en BPMN (Weidlich et al.
2008). Cependant, nous assistons des pertes de considrations de conception dans les modles
implments lors du passage BPMN-BPEL. De ce fait, le modle obtenu aprs une transformation BPEL-
BPMN est illisible pour un analyste mtier (et donc inutile). Par exemple, labsence de labels sur les
activits et transitions et une rpartition des lments travers le modle diffrente de celui dorigine le
rende difficile lire.
XPDL (XML Process Definition Language) est un format standardis par la WfMC (Workflow
Management Coalition). La version actuelle, 2.1, a pour vocation de reprsenter tous les concepts de BPMN
sous un format XML, de devenir son format dchange standard
15
. Ainsi un mapping direct (dlments
simples) est possible depuis un modle BPMN vers un modle XPDL. XPDL dcrit la reprsentation
graphique des lments de manire textuelle (coordonnes XY, taille des nuds...). Associ au BPMN,
il permettrait ce dernier de disposer dun format dchange de modles et ainsi augmenter sa
portabilit. Associ au sein dune chane BPMN-XPDL-BPEL (Palmer 2006), il permettrait de conserver et
restituer laspect original dun modle, mme aprs sa transformation en BPEL.
Si BPEL sert dexemple dans notre manuscrit et aide caractriser les lments du mtamodle
pivot, XPDL et BPMN resteront les standards sur lesquels nous nous appuierons pour dvelopper notre
plateforme Solution pour la Cohrence et lALignement des Processus (SCALP) (cf. chapitre 10).
REMARQUE : BPMN 2.0
Selon (Silver 2008) la version 2.0 n'a pas rpondu toutes les attentes mais a fourni des solutions concrtes sur un
certain nombre de points. Les points nous intressants le plus, vis--vis de notre approche sont les suivants :
- BPMN 2.0 permet-il une meilleure portabilit, facilitant les transformations entre environnements de
modlisation et dimplmentation ?
BPMN 2.0 affiche la volont de devenir un langage de modlisation excutable et ainsi de se passer de BPEL.
Nanmoins, le schma d'change standard bas sur XML propos pour l'change de modles excutables se rvle

14
Voir www.oasis-open.org
15
Voir http://www.wfmc.org/xpdl.html
9. CONCEPTION 107

insuffisant. De la mme manire, lexportation dun modle BPMN depuis un outil un autre, se ralise non pas
laide dun schma XML standard mais avec une librairie nomme "M1 library". Ceci contribue compliquer la
portabilit du contenu du modle avec des outils bass sur XML.
- BPMN 2.0 permet-il de spcifier des informations non-excutables, relevant de la smantique mtier ?
BPMN ne propose pas de solutions permettant une distinction franche entre smantique des modles excutables et
non excutables (BPMS.Info 2009). BPMN prsume qu'essentiellement la smantique des modles excutables et
non excutables est la mme, en ralit. Hors ceci nest pas forcment vrifi. Considrons une orchestration o,
lorsquune activit A est termine, l'activit B dmarre immdiatement. Un moteur de workflow fonctionne
traditionnellement de cette manire. Considrons maintenant que nous dsirons, dans un modle non-excutable,
pouvoir spcifier que l'activit B ne s'excute pas ncessairement tout de suite aprs (cela arrive souvent un
niveau peu dtaill). Cet ajout dinformation non visible dans le modle nest pas pris en compte par le BPMN 2.0.
Ainsi linformation ne peut tre transmise d'un outil un autre.
Cette prsentation succincte de BPMN 2.0 peut sembler trs ngative. Il faut cependant se rappeler quil ne sagit
pas dune valuation du standard. Nous cherchons juste mettre en avant les caractristiques manquantes BPMN
1.2 et BPMN 2.0 et ayant un impact sur notre approche.

9.5 DEFINITION DU METAMODELE PIVOT
Pour dfinir notre mtamodle pivot, nous commenons par dterminer les lments le
caractrisant. Sinspirant des trois standards dcrits prcdemment, ces lments sont choisis selon
deux critres : leur frquence dutilisation au sein de modles de processus et leur appartenance ou non
une des classes de conformit du standard XPDL.
9.5.1 Elments de modlisation des processus mtier
Afin de permettre une reprsentation plus fine des processus mtier, les langages de modlisation
se sont complexifis au fil des annes. Cette complexit se justifie de la manire suivante : en dtaillant
plus finement un processus, nous facilitons sa transformation vers le modle dimplmentation
correspondant.
Cependant, leffet est tout autre. La prolifration des concepts nuit la comprhension et
augmente la difficult dune transformation. (Zur Muehlen and Recker 2008) a ralis une tude portant
sur 126 modles BPMN, issus de corps de mtier htroclites. Lobjectif de cette tude est de dterminer
quels concepts dfinissant le vocabulaire de BPMN sont les plus utiliss, et quelle frquence. Cette
frquence est reprsente sur le Tableau 5.
Sur les 50 concepts dfinissant le vocabulaire de BPMN 1.2, moins de 20% est en ralit utilis.
Seulement quatre lments sont utiliss plus de 50% par les analystes mtier : lactivit de type tche,
la reprsentation du flux normal, les vnements de dbut et de fin dune squence dactivit, la porte
logique XOR (OU exclusif) et llment Pool (groupement).


Tableau 5. Frquence doccurrence des constructs BPMN

Notre approche utilise 18 objets qui constituent notre mtamodle pivot. Ils sont entours sur le
Tableau 5. Nous voyons quils reprsentent lensemble du groupe BPMN Common Core et la majorit des
lments du groupe BPMN Extended Core. Il sagit majoritairement des lments les plus utiliss en
entreprises. Pour plus de clart, ces lments sont catgoriss selon cinq groupes et sont reports sur le
Tableau 6. Nous rduisons ainsi lexpressivit du langage (Ulmer et al. 2008) en limitant son nombre
dlments, rduisant notre champ dtude et assurant une transformation des modles de ce langage
vers dautres types de langages (comme des langages dexcution) sans ambigit. En effet, les
langages de modlisation utiliss ont volu au cours du temps afin daugmenter leur expressivit et
dtre plus complets. Ces volutions ont permis, dans une certaine mesure, une meilleure interprtation
9. CONCEPTION 109

de ces langages par des experts SITI. Nanmoins, ces volutions ont rendu ces langages plus
complexes, sans pour autant pallier les divergences smantiques et structurelles existantes entre
modles conceptuels issus des langages de modlisation et modles techniques provenant des langages
dimplmentation. Ce nombre restreint dlments permet nanmoins de modliser la plupart des
processus rencontrs en industrie comme nous venons de le voir (Zur Muehlen & Recker 2008).
Certains lments, bien quutiliss 25 pour cent ou moins par les entreprises font partie de notre
slection. Ce choix dlments nest pas anodin, lensemble des lments choisis constituent la classe
simple de conformit de portabilit de modle ou model portability conformance class. Ces classes, dfinies
dans (WfMC, 2008) sont au nombre de trois (Simple, Standard, Complte). Un outil de modlisation
certifiant appartenir lune de ces classes doit pouvoir importer et comprendre chacun des lments
constituant cette classe. Nous tendons cette dfinition notre tude, dans laquelle un outil BPI doit
pouvoir importer et comprendre un modle BPA et un outil BPA un modle BPI. Chacun de ces modles
doit galement possder un modle pivot quivalent. La Figure 46 illustre les concepts utiliss dans notre
dmarche et leurs relations structurelles laide dun diagramme de classe, ici en Ecore.
Tableau 6. Elments constituant le mtamodle pivot
N
Famille
dlments
Type N
Famille
dlments
Type
1
Node
Event
Start 11
Edge
Uncontrolled
2 End 12 Conditional
3
Action
Task 13 Default
4 Activity 14 Association
5 Sub-Process 15
Artefact
Objet data
6
Logical
Exclusive 16 Annotation
7 Inclusive 17
Special
BPElement
8 Parallal 18 Process
9
Swimlane
Pool
10 Lane

Le langage BPMN tant largement rpandu, nous ne fournissons pas une prsentation exhaustive
de tous ses lments. La thse de (Touzi 2007) prsente en dtail les diffrents lments de ce langage
et (Silver 2009) en dfinit les bonnes pratiques.
Chacun des lments de notre mtamodle pivot possde les attributs suivants :
Tableau 7. Attributs communs tous les lments
Nom de lattribut Type Description
name string Nom de llment
id string Id de llment (unique)
hasSpecialProperties BPElement Dfinit les proprits spcifiques de llment
Dans la suite de ce chapitre, nous dfinissons les lments et les attributs spcifiques qui y sont
rattachs.


Figure 46. Mtamodle pivot
9. CONCEPTION 111

9.5.2 Famille dlments : Special
Ce groupe rassemble deux lments supplmentaires par rapport ceux choisis : Process et
BPElement. Llment Process est lobjet englobant lensemble des autres lments exprims dans le
Tableau 6. Dans notre approche, nous ne considrons quun processus par modle. Ainsi cet lment
Process peut tre assimil au diagramme de processus mtier, Business Process Diagram- BPD (Tableau 7).
Tableau 8. Attribut de llment Process
pools Pool Indique les lments Pool contenus dans llment
Le deuxime lment est la classe BPElement. Cette classe permet de prendre en considration
des informations ninfluenant pas le modle BPA et/ou le modle BPI mais juges ncessaires dans un
but de rtro-ingnierie des processus.
BPElement
Reconsidrons les modles de lexemple vus au chapitre 7. Lors de la transformation du modle
(a) vers le modle (b), les informations graphiques ntaient pas considres. Dans lapproche que nous
proposons, la transformation ne se fait pas directement, nous passons par un modle intermdiaire, le
modle pivot.

A laide de la classe BPElement, nous conservons les donnes relatives laspect graphique du
modle BPA et de manire plus gnrale, relatives aux notions de mtier exprimes dans le modle BPA
et non prises en compte dans le modle BPI. Considrons lextrait du modle pivot Figure 48.
A B
(a)

<repeatUntil >
<sequence>
<invoke name="A"
<invoke name="B"
</sequence>
</repeatUntil>

(b)
Figure 47. Modle BPA et modle BPI

La tche A possde les donnes retranscrites dans le modle pivot en tant que GraphicalAttributes
(Figure 49). Nous oprons de la mme manire lors de la transformation inverse (modle BPI vers le
modle BPA), les donnes inutilises par lanalyste mtier tant retranscrites en tant que ImplAttributes.
Les attributs de BPElement sont dfinis par larchitecte des processus en accord avec lanalyste
mtier et lexpert SITI (Tableau 8). La prsence de ces deux experts est requise afin de dterminer les
donnes qui sont utiles et communes aux deux modles et les donnes qui sont spcifiques chacun de
ces modles.

Figure 49. Proprits graphiques de llment Task A
Tableau 9. Attribut de llment BPElement
isAGraphicalElement GraphicalAttributes Dfinit les lments graphiques de llment (coordonnes, forme, )
hasImplInformation ImplAttributes Dfinit les lments utiliss lors de lexcution du processus (import, type de
donnes,)
9.5.3 Groupe Node
Cette famille regroupe les composants de modlisation dcrivant le control-flow du processus.
Chacun de ces lments peut tre peru comme un nud (par opposition au terme lien) et peut
possder un lien entrant ou sortant. Ce groupe se subdivise en trois sous-types : les vnements, les
actions et les lments logiques.
Evnement
Les vnements dcrivent un vnement qui se produit durant lexcution du processus. Ces
vnements affectent le control-flowdu processus et possdent usuellement une cause (dclencheur) ou
un impact (rsultat). Dans notre cas, nous considrons quun processus dbute par un Start Event et se
termine avec un End Event. Ces deux lments sont reprsents par llment Event du mtamodle
pivot. Lattribut eventTypes est une numration indiquant si lvnement cibl est de type start ou de
type end (Tableau 9).
Figure 48. Extrait du modle pivot
9. CONCEPTION 113

Tableau 10. Attribut de llment Event
eventTypes Enumration Dfinit le type de llment (0 : start ; 1 : end)
Action
Les nuds de type action reprsentent les lments ralisant une activit, une tche ou un
ensemble de ces derniers durant le droulement du processus.
Llment Task reprsente une activit atomique, signifiant quelle ne peut tre reprsente
comme un ensemble de nuds dans ce diagramme de processus. Le mtamodle pivot ralise la
distinction entre une User task ralise par une personne et une Service task ralise de manire
automatise. Cette distinction est faite laide de lattribut taskTypes (Tableau 10).
Tableau 11. Attribut de llment Task
taskTypes Enumration Dfinit le type de llment (0 : none ; 1 : user task ; 2 : service task)
Llment Activity regroupe un ensemble de tches - Task relies entre elles par des liens Edge
(Tableau 11).
Tableau 12. Attribut de llment Activity
nodes Node Indique les lments Node contenus dans llment
edges Edge Indique les lments Edge contenus dans llment
isPerformedBy Lane Indique llment Lane le contenant
Et llment Sub-Process regroupe un ensemble dactivits et de liens (Tableau 12).
Tableau 13. Attribut de llment SubProcess
isConstituedBy Activity Indique les lments Activitycontenus dans llment
hasEdges Edge Indique les lments Edge contenus dans llment
Logical
Une porte logique reprsente un point de contrle dans le sequence-flowdu processus. Ces portes
permettent de sparer ou de rassembler les multiples flux dun processus sous certaines conditions.
Dans notre mtamodle, ces portes sont reprsentes par llment Logical et lattribut logicalTypes
permet de faire la distinction entre les types OU, ET et OU Exclusif (Tableau 13).
Tableau 14. Attribut de llment Logical
logicalTypes Enumration Dfinit le type de llment (0 : AND ; 1 : OR ; 2 : XOR)
9.5.4 Groupe Edge
Ce groupe dcrit les diffrents lments permettant le sequence-flowdu processus. Ces lments
reprsentent les liens existants entre les nuds et avec les artefacts. Dans notre mtamodle pivot, un
seul lment permet de tous les reprsenter, llment Edge. Lattribut edgeType permet de dfinir quel
type de lien est reprsent par llment Edge (Tableau 14):

(0) Uncontrolled : le lien est franchi ds que possible (si le nud source est excut) ;
(1) Conditional : le lien est franchi ds que possible et si la condition porte sur la transition est
vraie ;
(2) Default : ce lien est franchi par dfaut ;
(3) Association : ce lien permet de relier un artefact un autre lment du diagramme.
Tableau 15. Attribut de llment Edge
toNode Node Indique le noeud-cible de larc
fromNode Node Indique le noeud-source de larc
edgeType Enumration Dfinit le type de llment (0 : Uncontrolled ; 1 : Conditional ; 2 : Default ; 3 :
Association)
9.5.5 Groupe Swimlane
Ce groupe rassemble les lments utiliss pour dfinir la typologie des participants.
Pool
Llment Pool est le contenant dun processus. Techniquement, il reprsente un participant (un
rle ou une entit mtier) et contient une ou plusieurs Lanes (Tableau 15).
Tableau 16. Attribut de llment Pool
lanes Lane Indique les lments Lane contenus dans llment
Lane
Une Lane est une sous-division du processus et reprsente le rle dun excutant ou dune unit
organisationnelle du processus. Elle contient une ou plusieurs activits et sous-processus (Tableau 16).
Tableau 17. Attribut de llment Lane
activities Activity Indique les lments Activity contenus dans llment
subProcesses SubProcess Indique les lments SubProcess contenus dans llment
REMARQUE : ELEMENT POOL
Bien que llment pool soit prsent, cette approche ne prend pas en considration, pour le moment, la
chorgraphie entre processus de collaboration.

9.5.6 Groupe Artefact
Les lments de ce groupe sont atypiques par rapport aux autres prsents prcdemment. Ils ne
possdent pas de smantique clairement dfinie. LObjectData peut tre utilis pour reprsenter une
donne ou un document prsent dans le flux entre les activits et les vnements dun processus.
LAnnotation est un texte arbitraire qui peut tre insr dans le diagramme de processus et tre reli un
autre lment.
9. CONCEPTION 115

9.6 CARACTERISATION DES LIENS SEMANTIQUES
Pour identifier les liens smantiques existants entre les lments de deux modles, nous nous
appuierons sur les dfinitions dquivalences smantiques issues de (Rizopoulos et Mbrien 2005).
9.6.1 Typologie des liens smantiques
Les auteurs considrent que les relations smantiques sont dfinies selon les domaines
intentionnels (nots Di(A) et Di(B)), c'est--dire que les objets du monde rels sont associs aux
concepts des modles A et B. Nous avons les quatre rgles suivantes :
Equivalence : les concepts de A et B sont quivalents si et seulement si

A
S
= B ssi Di(A) = Di(B)
(14)
Subsumption ou gnralisation : A est une subsumption de B si et seulement si

B
S
cA ssi Di(B) c Di(A)
(15)
A loppos, B est une spcialisation de A (ou subsumption inverse).
Intersection : les concepts de A et B sentrecroisent si et seulement si

A
S
B ssi Di(A) Di(B) = 0, - C : Di(A) Di(B) = Di(C)
(16)
Disjonction : A et B sont disjoints si et seulement si

A
S
/
B, - C : Di(A) Di(B) _ Di(C)
(17)
Le s prsent sur les symboles dsigne le fait que les lments sont considrs dun point de
vue purement smantique. A laide de ces relations, nous pouvons identifier les liens smantiques
existants entre les lments constituant notre mtamodle pivot et ceux des mtamodles BPA et BPI.
Ces relations seront utilises afin de dterminer les quivalences smantiques existantes entre les
diffrents mtamodles manipuls par notre plateforme SCALP (Chapitre 10). Avant cela, nous
prsentons dans la section suivante un exemple dapplication de ces relations avec les standards les plus
reprsentatifs des processus mtier : BPMN, BPEL et XPDL.
9.6.2 Exemple dquivalence smantique
Afin dillustrer lutilisation des liens smantiques prsents prcdemment, nous utilisons le
triptyque suivant : <BPMN, XPDL, BPEL>. Le Tableau 18 montre les quivalences smantiques
existantes entre les diffrents lments de ces mtamodles.
Le one-to-one mapping est ralisable entre lments du standard BPMN et ceux du standard
XPDL. Nous remarquons que les lments de la famille Swimlane ne sont pas pris en compte par
BPEL. En effet, llment Pool na pas son quivalent smantique dans les langages dexcution. De

manire identique, llment Lane na pas dquivalent smantique dans les langages dexcution.
Son rle tant dindiquer comment les activits sont groupes au sein du processus mtier, il est obsolte
dans un langage de modlisation.
Tableau 18. Exemples dquivalence smantique entre BPMN, XPDL et BPEL
Elments BPMN
(A)
Relation
smantique
Elments XPDL (B)
Relation
smantique
Elments BPEL (C)
None Start
A
S
= B
Start (None)
C
S
cB
{receive, pick}
Collapsed Sub-
Process A
S
= B
Activity Set/ Block
Activity B
S
= C
scope
Parallel Gateway
A
S
= B
Route (Join OR/Join
AND), (Split AND) B
S
cC
flow
Pool
A
S
= B
Pool Aucune correspondance
Lane
A
S
= B
Lane Aucune correspondance
Data Object
A
S
= B
Artifact (DataObject)
B
S
C
documentation
Text Annotation
A
S
= B
Artifact (Annotation)
B
S
C
documentation

9.7 FORMATION DES METAMODELES BPA ET BPI
Dans ce paragraphe, nous allons dfinir dune manire trs squentielle la formation dun
mtamodle MM
i
. Nous supposons quun langage de modlisation ou dune application SI permettant
lexcution des processus, selon nous concevons un mtamodle BPA ou BPI, est disponible.
Maintenant, dtaillons la cration du mtamodle tapes par tapes, retranscrites Figure 50 :
- Etape 1. Le mtamodle MMi existe-t-il ? Sil en existe une reprsentation formelle, alors
nous pouvons passer ltape 3. Dans les autres cas, il faut considrer ltape 2.
- Etape 2. Nous commenons par effectuer une comparaison entre lments appartenant au
langage de modlisation. Nous constituons le MM
i
en nous inspirant du MM
Pivot
, en identifiant les
lments communs aux deux mtamodles. Le MM
Rep
est ainsi cr.
- Etape 3. Nous cherchons maintenant dterminer le RefMet du mtamodle. Nous
dfinissons les rgles non-structurelles devant sappliquer aux diffrents lments dtermins
durant ltape prcdente.
- Etape 4. Puis nous procdons lidentification des lments appartenant au MM
i
ayant un
quivalent smantique au sein du MM
Pivot
. Les rgles dquivalences exposes section 9.6 sont
utilises cet effet. Si tous les lments du MMi ont un quivalent, alors nous pouvons poursuivre
avec ltape 6. Dans le cas contraire, il faut se poser la question suivante : sagit-il dun problme
dattributs ? Si cest le cas, alors il faut considrer ltape 5. Sinon, il faut reprendre ltape 2.
- Etape 5. Ici, llment BPElement du MM
Pivot
est utilis pour dfinir les attributs manquants
dun lment. Llment BPElement appartient au MM
Pivot
. Il permet de rajouter des attributs de
type BPA ou BPI un lment quelconque du MM
Pivot
.
- Etape 6. Le mtamodle est correctement form. Nous pouvons ds lors constituer notre
plateforme solution permettant la transformation dun modle issu dun environnement vers un
autre. Tout ceci est expliqu dans la quatrime partie : Mise en uvre.
9. CONCEPTION 117

Figure 50. Formation dun MM
i

9.8 CONCLUSION
A laide de concepts issus de lIDM, nous pouvons justifier les relations de cohrence entre
modles. En appliquant la mthode prsente dans la section prcdente, nous systmatisons
lutilisation de mtamodles BPA et BPI dans notre approche. Afin datteindre un alignement
oprationnel, il nous faut au pralable obtenir une transformation bidirectionnelle entre modle BPA et
modle BPI. Nous avons cet effet prsent la ncessit de passer par un systme intermdiaire, le
modle pivot. Son mtamodle est dfini selon deux critres : selon la classe simple de conformit
propose par le standard XPDL et selon les lments les plus utiliss au sein des modles de processus
mtier.
Les transformations utilises dans lapproche propose permettant dassurer la synchronisation et
la cohrence intermodle, sont justifies laide de fonctions de conformit constructive. De part la
complexit en rsultant, lutilisation dune telle approche nest pas indique dans des dmarches de
Etape 1
Etape 2 Etape 3
Etape 4
Etape 5
Etape 6
Fin
Dbut
MM formel ?

MMRep cre
RefMet cre
BPElement
dfini
Equivalences smantiques ?
Elments prsents et
attributs manquants ?
MM formel
dfini

transformations unilatrales, dun domaine vers un autre. Cette approche devient rellement utile dans
des dmarches de rtro-ingnierie, ou pour conserver un modle danalyse jour .

QUATRIEME PARTIE
D. MISE EN UVRE
10. Plateforme Solution pour une Cohrence et un ALignement des Processus 121
11. Dmonstration 137
12. Ingnierie des processus au service de lingnierie des procds 157

120 D. MISE EN UVRE

RESUME
Pour confirmer notre approche thorique voque dans la partie prcdente, nous menons un
projet de dveloppement logiciel. Le rsultat de ce projet, la plateforme Solution pour la Cohrence et
lALignmenet des Processus SCALP, est dcrit. Puis nous prsentons un cas dtude afin de mettant
en uvre notre approche. Un processus utilis en industrie est manipul depuis sa modlisation jusqu
sa transformation en module fonctionnel pour un logiciel de type ERP. Nous prsentons aussi nos
travaux de recherche relatifs la possible adquation entre lingnierie des processus et lingnierie des
procds. Nous pensons quune telle adquation est possible travers lutilisation de notre approche
pivot, et nous cherchons le dmontrer.

10. Plateforme Solution pour une Cohrence et un
ALignement des Processus - SCALP
Afin de valider les diffrentes proprits proposes tout au long de ce manuscrit, nous prsentons
un prototype logiciel mettant en uvre et validant notre approche. Lobjectif de ce prototype est de
permettre concrtement la cohrence des modles issus du domaine mtier et du domaine SITI et
amliorer ainsi lalignement oprationnel entre processus dentreprise et systme dinformation.

C
H
A
P
I
T
R
E

10
122 D. MISE EN UVRE

10.1 ARCHITECTURE GENERALE DE LA PLATEFORME SCALP
Cette plateforme solution est base sur les trois environnements pris en compte dans notre
approche :
- Un environnement de modlisation, o un modle conceptuel de processus est dessin par
un analyste mtier. La fonctionnalit dcoulant de cet environnement est la modlisation du
processus mtier. A cet effet, nous utilisons loutil de modlisation Intalio Designer 6.0.3
16
;
- Un environnement dimplmentation, comprenant la plateforme cible dexcution. Cest au
sein de cet environnement que lexpert SITI modifie le modle dentre obtenu, de manire le
rendre excutable. Le moteur dexcution de processus utilis est un ERP, OpenERP 5.0.14
17
;
- Un environnement pivot, contenant la plateforme pivot. Cette plateforme comporte deux
fonctionnalits bien distinctes : la transformation dun modle provenant dun environnement (le
modle dentre) vers un autre (le modle de sortie) et la prservation de lintgrit des
informations contenues dans le modle dentre. Pour instancier cette plateforme pivot, nous
utilisons le framework EMF 1.4.0 (Eclipse Modelling Framework)
18
de lIDE (Integrated
Development Environment) Eclipse 3.4.2
19
. La mtamodlisation est ralise laide dEcore 0.7.0
et est appuye par le langage Kermeta
20
1.3.0 ( Kernel Metamodeling ).
La plateforme SCALP et les environnements considrs sont reprsents Figure 51. Si le
prototype obtenu repose sur des outils, lapproche mise en uvre reste indpendante des outils
technologiques utiliss. Nous dcrivons maintenant les diffrents outils composant notre plateforme et les
environnements.
10.2 ENVIRONNEMENT PIVOT
10.2.1 Eclipse Modeling Framework
EMF, dont linterface est expose Figure 52, est une plateforme de modlisation et de gnration
de code pour la construction doutils et dautres applications bases sur une structure de modle de
donnes (Steinberg et al. 2009).
EMF est donc une partie intgrante de la plate-forme Eclipse, permettant lutilisation des
technologies et cadres comme l'diteur Eclipse Visual, SDO, UML ou encore XSD. EMF est galement
dvelopp pour supporter les caractristiques de la technologie Java, telles que les types numrs,
annotations, etc.

16
http://www.intalio.com/bpms/designer
17
http://www.openerp.com/
18
http://www.eclipse.org/emf/
19
http://www.eclipse.org/
20
http://www.kermeta.org/
10. PLATEFORME SOLUTION POUR UNE COHERENCE ET UN ALIGNEMENT DES PROCESSUS - SCALP 123

Dvelopp par la fondation Eclipse, EMF sappuie sur un mta-mta-modle : Ecore. Ecore est
bas sur MOF ( Meta-Object Facility ) 2.0 et est identique lEMOF ( Eclipse Meta-Object Facility ),
tous deux prsents section 5.2.2. Ecore permet de dcrire les modles en reprsentant leurs
mtamodles ainsi quune srialisation des modles en XMI.
Plateforme SCALP
Environnement pivot
Environnement
danalyse
Environnement
dimplmentation
Intalio Designer
OpenERP
EMF
Kermeta
Figure 51. Plateforme SCALP
Figure 52. Interface EMF
124 D. MISE EN UVRE

Lobjectif dEMF est de fournir un ensemble doutils permettant la manipulation de modles et non
le comportement. Pour cela, la mtamodlisation, dfinie laide des outils Ecore, est complte par
lutilisation de Kermeta.
10.2.2 Kermeta
La mtamodlisation se fait laide dEcore et est appuye par la plateforme open-source de
mtamodlisation Kermeta ( Kernel Metamodeling ). Le langage Kermeta est une extension du
langage EMOF (Essential Meta-Object Facilities) dveloppe par lquipe Triskell
21.
Il sagit dune
extension ncessaire car les langages de mtamodlisation tel que EMOF sont uniquement en mesure
de modliser des structures comme des classes, attributs Le langage Kermeta permet de dfinir la
smantique oprationnelle et dnotationnelle dun mtamodle et le comportement des structures grce
son langage daction. Dnotationnelle car elle peut dcrire les relations entre diffrents types
dlments appartenant des formalismes diffrents (Muller, Fleurey, & Jzquel 2005). Ce langage
dfinit galement des mcanismes de liaison dynamique et de gestion des exceptions et des structures
de contrle classiques en langage impratif. Lune des caractristiques cls de Kermeta est sa capacit
tendre un mtamodle existant avec des contraintes, de nouveaux lments structuraux (mta-classes,
classes, proprits, et oprations) ou encore des fonctionnalits dfinies avec d'autres langages. Il sagit
du tissage daspect (Klein and Fleurey 2006). Ce tissage permet dajouter du code (une simple classe ou
un lment dun langage spcifique) au sein dun mtamodle cible sans pour autant en modifier la
structure (Mosser and Blay-Fornarino 2009).

21
https://www.irisa.fr/triskell/softwares-fr/kermeta/index_html
Figure 53. Mtamodle Ecore

Tout ceci contribue rendre le langage Kermeta comme tant un langage particulirement adapt
la dfinition de transformations de modles ou des contraintes stablissant sur les lments de ces
derniers. Kermeta permet de dcrire les transformations ainsi que les rgles mtier de manire
imprative. Les rgles mtier seront dcrites selon le standard SBVR (Semantic Business Vocabulary
and Business Rules).
10.3 ENVIRONNEMENT DE MODELISATION
Loutil BPA est reprsent par lapplication Intalio Designer 6.0.2
22
. Cet diteur permet de
modliser des modles de processus en utilisant une palette de symboles BPMN. Ainsi cet outil respecte
globalement la spcification du langage BPMN 1.2. Intalio Designer gnre deux fichiers exploitables et
libres au format XML. Prenons par exemple le diagramme reprsent Figure 54.

Intalio intgre une fonction de formatage de source afin de la rendre accessible un diteur XML.
Suite cette action nous obtenons deux fichiers en sortie, le premier fichier dtaille la logique du
processus (Figure 55), le second comporte les donnes relatives laspect graphique du processus
(Figure 56). Ces deux fichiers sont le point de dpart de notre plateforme.

22
http://www.intalioworks.com/products/bpm/opensource-edition/designer/
Figure 55. Extrait du fichier dentre Description logique
126 D. MISE EN UVRE

10.4 ENVIRONNEMENT DIMPLEMENTATION
Nous utilisons un ERP comme plateforme cible de lenvironnement BPI, OpenERP. Avant de
dcrire limplication de cette application au sein de la plateforme, nous prsentons succinctement les
ERP.
10.4.1 SI et ERP
Les ERP (Enterprise Resource Planning) ont t implments dans les annes 90 dans des
logiciels de gestion supports par des bases de donnes relationnelles, sans que leur concept de gestion
sous-jacent soit explicit. Traduits en franais par Progiciels de Gestion Intgr (PGI) (Lequeux
2008), la plupart des solutions informatiques actuelles proposent un traitement intgr et synchronis des
donnes. Ainsi, ces solutions reposent essentiellement sur des concepts issus du traitement de
linformation et non sur des concepts issus de la gestion et des sciences de lorganisation. Et bien que les
ERP doivent sappuyer sur les processus, (Bidan 2004) constate quils sintgrent par les donnes.
Lun des enjeux avous du BPM est de parvenir extirper les processus mtier des applications
o ils ont t dissimuls lors dune approche ERP.
10.4.2 Ct technique
Un module OpenERP se traduit par un dossier contenant cinq types de fichiers qui sont sous
format python (.py) et xml. Exploitant notre framework dvelopp en Java-XML, cet exemple repose donc
sur le triptyque Intalio Designer, EMF-Kermeta et OpenERP. La Figure 57 est un extrait de la perspective
technique du modle.
Le fichier __terp__.py (a) est une description du module indiquant le nom du module, sa version,
ses dpendances vis--vis dautres modules, etc. Le fichier __init__.py (b) est un fichier de dmarrage
indiquant les imports effectuer lors du lancement du module, notamment les wizards associs au
module. Un fichier nomModule.py dcrit les classes spcifiques au module (c). Ces classes dcrivent les
formulaires associs au module. Elles dfinissent galement la structure de linterface. Enfin la dernire
catgorie de fichiers regroupe les fichiers en .xml, dans lesquels nous fournissons une description du
squencement dactivits du module (nomModule_workflow.xml) (d), ou encore son interface
(nomModule_view.xml) (e).
Figure 56. Extrait du fichier dentre Attributs graphiques

Un exemple de fichiers constituant le module OpenERP est prsent en annexes, section 15.4.3.
a

b

c

d

e

Figure 57. Fichiers de sortie pour le module OpenERP
128 D. MISE EN UVRE

P
l
a
t
e
f
o
r
m
e

S
C
A
L
P

E
n
v
i
r
o
n
n
e
m
e
n
t

d
i
m
p
l
m
e
n
t
a
t
i
o
n

P
r
o
g
i
c
i
e
l

d
e

G
e
s
t
i
o
n

E
n
v
i
r
o
n
n
e
m
e
n
t

d
a
n
a
l
y
s
e

O
u
t
i
l

d
e

m
o
d
l
i
s
a
t
i
o
n

F
i
c
h
i
e
r

I
n
t
a
l
i
o

.
x
m
l
/

.
b
p
m
n

M
o
d
u
l
e

O
p
e
n
E
R
P

M
M
B
P
A

m
B
P
A

.
x
m
l
/
.
x
m
i

M
M
R
e
p

.
e
c
o
r
e

R
e
f
M
e
t

.
k
m
t

(
S
B
V
R
)

(
t
1
)

(
t
2
)

(
t
6
)

(
t
3
)

(
t
5
)

(
t
4
)

(
m
1
)

(
m
2
)

(
m
3
)

(
m
4
)

(
t
1
)

(
t
4
)

E
n
v
i
r
o
n
n
e
m
e
n
t

p
i
v
o
t

M
M
B
P
I

M
M
R
e
p

.
e
c
o
r
e

R
e
f
M
e
t

.
k
m
t

(
a
)

m
B
P
I

.
x
m
i

M
M
P
i
v
o
t

M
M
R
e
p

.
e
c
o
r
e

m
P
i
v
o
t

.
x
m
i

F
r
a
m
e
w
o
r
k

-

.
j
a
v
a
,

.
x
m
l
,

.
p
y
,

.
e
c
o
r
e
,

.
k
m
t

R
e
f
M
e
t

.
k
m
t

Figure 58. Architecture du framework logiciel

REMARQUE
Nous considrons quun processus mtier compos de n-pools quivaut n modules OpenERP. Dans un souci de
simplification, lexemple considr dans ce manuscrit traite le cas dun processus mtier constitu dun pool unique.
Par ailleurs, nous nous concentrons sur les processus mtier de type control-flow. Ils nous permettent dobtenir la
description dun squencement dactivits au sein du module ERP.

10.5 IMPLEMENTATION DES MAPPINGS ET TRANSFORMATIONS
En reconsidrant la Figure 43 (chapitre 9) et la Figure 51, nous obtenons la Figure 58. Elle illustre
les oprations ncessaires au passage dun modle conceptuel issu de loutil de modlisation Intalio
Designer vers un modle technique et son module OpenERP correspondant.
Le (a), prsent dans le RefMet du MM
BPI
, dsigne lensemble des rgles et contraintes que nous
avons rencontres lors de la ralisation de lenvironnement dimplmentation. Nous avons assimil cet
ensemble comme tant le RefMet de notre mtamodle BPI.
Les mappings m1 et m2 reprsentent les oprations de mappings que nous effectuons depuis le
MM
BPA
vers le MM
Pivot
et inversement. De mme, les mappings m3 et m4 reprsentent les mappings
depuis le MM
Pivot
vers le MM
BPI
et inversement.
Les transformations t1 et t4 dsignent les oprations ncessaires pour importer les modles ou
fichiers depuis les applications Intalio Designer et OpenERP vers la plateforme SCALP. A linverse, les
transformations t1 et t4 permettent de transformer les modles issus de la plateforme SCALP en
modles utilisables par lesdites applications. Enfin, les transformations t2 et t5 permettent respectivement
de transformer un m
BPA
en un m
Pivot
et un m
BPI
en un m
Pivot
. Les transformations t6 et t3 ralisent les
oprations inverses.
10.5.1 Mtamodles BPA et BPI
Pralablement ces transformations, les mappings (m1, m2, m3, m4) entre MM
i
et MM
Pivot
doivent
tre raliss. Or nous navons pas, ici, de mtamodles existants ou bien-dfinis. Nous dterminons les
mtamodles en suivant la mthode indique section 9.7 puis nous les retranscrivons sous format Ecore.
Les quivalences smantiques sont dtailles dans la partie 11 : Dmonstration. Les deux mtamodles
obtenus sont reprsents Figure 59 et Figure 60. La dfinition du mtamodle pivot est discute section
9.5.
Les diffrents mappings sont raliss laide de Kermeta. Kermeta peut tre utilis comme un
tisseur daspect adapt aux mtamodles Ecore, capable de les manipuler sans les modifier. Pour cela,
Kermeta utilise le patternVisiteur que prsente la section suivante.
130 D. MISE EN UVRE

Figure 59. Mtamodle BPA

10.5.2 Pattern Visiteur
La dfinition dune transformation, selon ce pattern Visiteur, revient dfinir un (ou plusieurs)
visiteur(s), au sens motif de conception Visiteur (Gamma, Helm, Johnson, & Vlissides 1999) (Figure 61).
Figure 60. Mtamodle BPI
132 D. MISE EN UVRE

Le pattern Visiteur requiert d'implanter une opration visitElement dans la classe MMVisitor (Figure
62 (a) ici IntalioVisitor) et une opration accept dans la classe visite ConcreteElement (Figure 62 (b)
par exemple BpmnDiagram). Lors dune transformation (autre que t1, t1 et t4, t4) depuis un modle
source vers un modle cible, les classes du modle cible ont une association dirige vers les classes du
mtamodle du modle source (dans cet exemple, le m
BPA
vers le m
Pivot
). Ainsi, si une classe du modle
cible a besoin de rcuprer une valeur d'une proprit d'un lment du modle source, elle peut
directement le faire au niveau de linterface visiteur. Les proprits ainsi que leurs valeurs ne sont pas
redfinies au niveau de la classe du modle cible, elles sont conserves. Cette approche permet donc au
modle cible de rcuprer les valeurs des attributs du modle source sans avoir modifier leur
mtamodle.
Lutilisation de ce motif facilite laddition doprations pouvant tre requises lors des
transformations. En effet, chaque nouvelle opration sur le mtamodle se traduit par lajout dun
nouveau visiteur. A loppos, laddition dun nouvel lment est difficile : pour chaque lment une
nouvelle opration dans chaque visiteur doit tre cre. Nanmoins, si un certain niveau de maturit est
atteint dans lentreprise, nous prsumons qu travers notre approche, nous modifions/ajoutons/retirons
plus souvent les oprations ralises par les mtamodles quils ne changent.
Aprs avoir cr nos mtamodles et dcrit la notion de visiteur, nous abordons la mise en uvre
des mappings et des transformations de modles.
SuperVisitor
visitElement (Element : Object)
MMVisitor
visitElement (Element : Object)
Element
accept (Visitor : Object)
ConcreteElement
accept (Visitor : Object)
Client

Figure 61. Diagramme de classe du pattern Visiteur selon (Gamma et al. 1999)

a

b
Figure 62. Pattern de conception Visiteur, en langage Kermeta
134 D. MISE EN UVRE

10.5.3 Mappings et transformations
La transformation t1 permet dassocier les deux fichiers issus de loutil de modlisation Intalio
Designer. Il sagit des fichiers Description logique et Attributs graphiques que nous avons
prsents prcdemment. Leur association permet dobtenir notre m
BPA
. Cette premire transformation
se fait laide du parseur XML JDOM
23
. Afin de valider le modle obtenu, nous lui prcisons le schma
XML, reprsent ici par le MM
BPA
.
A linverse, t1 spare les informations contenues dans m
BPA
selon quil sagisse dune information
destine au fichier Description logique ou au fichier Attributs graphiques .
Les transformations t2, t3, t5, et t6 se font laide de latelier de mtamodlisation utilisant
Kermeta. Le mapping m1 se ralise aprs lutilisation dun visiteur dterminant et associant les lments
des mtamodles BPA et pivot. Ceci permet au framework deffectuer la transformation t2, du modle
BPA vers le modle pivot, selon une mthode Builder-Linker. Nous oprons de la mme manire pour
transformer le modle pivot en un m
BPI
(m3, t3).
La transformation t4 est atypique par rapport aux autres transformations. En effet, la transformation
t4 du m
BPI
fournit un module OpenERP contenant les cinq fichiers explicits en 3.1. Cette transformation
est semi-automatise ainsi que son inverse (t4). En effet, si des informations issues du m
BPI
sont utilises
lors de la gnration du fichier module_View.xml, ce dernier se concentre essentiellement sur linterface
utilisateur. Cet aspect ntant pas pris en compte dans nos processus mtier, le fichier module_View.xml
ncessite dtre manipul manuellement.
10.6 CONCLUSION
Afin de montrer lintrt de notre approche, nous proposons une plateforme mettant en uvre une
Solution pour la Cohrence et lALignement des Processus. Notre plateforme exploiteur des applications
logicielles sans compatibilit particulire et est dveloppe partir des technologies de linformation. Elle
manipule et fournit ainsi des modles htrognes (Tableau 19).
Tableau 19. Applications et technologies utilises par la plateforme SCALP
Niveau Outil de
modlisation
Environnement
danalyse
Environnement
pivot
Environnement
dimplmentation
Progiciel de
Gestion
Applications,
applicatifs
Intalio Designer 6.0.2 Ecore 0.7.0, EMF
1.4.0, XML JDom
Ecore 0.7.0, EMF
1.4.0, XML JDom,
Kermeta 1.3.0
Ecore 0.7.0, EMF 1.4.0,
XML JDom
OpenERP 5.0.14
PGAdmin III
Technologies,
langages
BPMN, XML XML, XMI, Java XML, XMI, Java XML, XMI, Java Python,
PostgreSQL, XML
Format des
fichiers
.bpmn,
.bpmn_diagram
.xmi, .ecore, .java .xmi, .ecore, .java,
.kmt
.xmi, .ecore, .java .xml, .py
Lenvironnement danalyse et lenvironnement dimplmentation ne proposent pas de mtamodles
au sens strict. Ainsi, aprs avoir constitu nos mtamodles selon la mthode expose au chapitre
prcdent, nous avons dfini les diffrentes tapes permettant la transformation dun modle de
processus depuis un environnement source vers un environnement cible. Pour y parvenir, notre

23
http://www.jdom.org/

plateforme sappuie sur lEMF et utilise le langage Kermeta. Ce dernier permet de dfinir les rgles de
comportement rgissant nos mtamodles et dutiliser le motif de conception Visiteur.
Nous proposons une dmonstration exploitant les diffrentes briques technologiques exposes
dans ce chapitre.

11. Dmonstration
La dmonstration que nous prsentons dans ce chapitre est un exemple de gnration de modles
depuis un diagramme de processus vers un module ERP. Nous montrons les diffrentes tapes ralisant
cette transformation et exposons certains de leurs dtails techniques.

C
H
A
P
I
T
R
E

11
138 D. MISE EN UVRE

a

c

b

Figure 63. Processus de rintgration de parfums
11. DEMONSTRATION 139

11.1 PRESENTATION DU PROCESSUS ETUDIE
Nous prsentons une exprimentation de notre plateforme logicielle avec un exemple de
processus reprsent Figure 63. Il sagit dun processus de rintgration de produits ayant subi un
contrle qualit. Ce processus a t rcemment mis en place par un grand groupe de cosmtique pour
ses units de production de parfum. Nous lutilisons ici comme un exemple de rfrence pour valider
notre plateforme et dmontrer notre approche explicite partie C.
Durant le conditionnement des produits, un pourcentage de la production est prlev afin dtre
contrl par le dpartement Qualit. Le lot prlev doit ensuite tre rinject dans le flux de production
afin dviter des pertes financires importantes. Cependant, les produits tests constituant ce lot sont
ouverts durant ce contrle. La rintgration concerne un flux de 300000 produits par an, selon 94 formats
de produits diffrents. Ceci implique de reconstruire l'emballage du produit avec un film cellophane sur
une ligne de fabrication adquate et de lencrypter contre le dtournement de produits. Un processus de
rintgration de parfums est alors dfini afin de rendre la majorit du lot rutilisable. Il est mis en place au
sein de lorganisation
Le processus commence lors du prlvement dun lot de produits sur une ligne de production. Le
lot est contrl par le laboratoire de Qualit. Les produits du lot prlev un instant t peuvent tre de
trois types diffrents (Figure 63 - a). (1) Les produits destins la vente ncessitent une tape de
cellophanage avant dtre envoys une centrale de distribution. (2) Les produits testeurs ne ncessitent
pas de cellophanage avant leur envoi en centrale distribution. (3) Les produits semi-finis ne ncessitent
pas non plus une tape de cellophanage mais requirent un traitement interne pour une ventuelle
utilisation future. Il faut galement considrer que ltape de cellophanage ne seffectue que sur une ligne
de production vide afin dviter des mlanges de numro de lot (Figure 63 - b). Avant leur envoi en
centrale, les lots constitus de produits de type 1 ou 2 suivent une tape de remise en conformit puis
une tape de constitution de palette (Figure 63 - c).
Le processus ainsi dfini est utilis travers le scnario de validation que nous exposons dans la
section suivante. Ses diffrents lments sont dfinis en dtail section 9.5. Nous allons voir comment ce
processus dessin laide dIntalio Designer devient un module ERP oprationnel ainsi que limpact de
notre dmarche sur les modles obtenus permettant leur cohrence intermodle.
11.2 SCENARIO DE VALIDATION
Afin de valider notre dmarche, nous proposons un scnario exposant les diffrentes oprations
subies par le processus et ses modles au cours de son cycle de vie. En partant de la phase BPA et dun
modle conceptuel, ce scnario dfinit les tapes ncessaires pour que ce processus puisse atteindre la
phase BPI et gnrer un modle technique. Afin de raliser son excution, ce modle peut tre modifi.
Nous prsentons alors les tapes ncessaires permettant de revenir en phase BPA et gnrer un modle
conceptuel adquat. Via ce scnario, nous souhaitons mettre en uvre les concepts de notre approche
et les mcanismes de notre plateforme. Il sagit de dmontrer que nous obtenons bien un meilleur
alignement oprationnel entre le domaine mtier et le domaine SITI. Un tel scnario est prsent Figure
64. Ce scnario est dcompos en trois grandes phases :
140 D. MISE EN UVRE

(1) Transformation dun modle conceptuel (BPA) vers un modle technique (BPI). Ce modle
technique ncessite un apport dinformation afin dtre utilisable. Cette premire phase permet
de montrer que la plateforme SCALP est en mesure de raliser une transformation
standard , depuis BPA vers BPI. Nanmoins lutilisation des fonctions de conformit
constructive et du modle pivot rsultant permet galement dobtenir systmatiquement un
modle mBPI conforme son mtamodle ;
(2) Restitution du modle graphique partir du modle technique ayant reu un ajout
dinformation. Nous considrons que mBPI a reu les modifications ncessaires son bon
fonctionnement par lexpert SITI. Pour simuler ces manipulations, nous procdons un ajout
dinformation fonctionnelle au niveau du module OpenERP et de ses fichiers (essentiellement
des fonctions codes en langage python) ainsi qu des modifications structurelles
(modification du control-flow par un ajout dactivit et des changements au niveau du
squencement). Au final, nous montrons que laspect graphique du diagramme de processus
peut tre restitu et est conserv, lexception des lments lis lactivit ajoute ;
(3) Modification du modle conceptuel obtenu et restitution du modle technique partir du
modle conceptuel. Lors de cette phase, nous simulons un changement dordre mtier et
ayant des rpercussions directes sur la reprsentation du processus de rintgration. Nous
considrons que lactivit Rceptionner le lot est dsormais supervis par un Responsable
de Ligne, et que suite cette activit, le responsable doit rdiger et archiver un document de
type nomenclature du lot. Le but de cette phase est de montrer que les informations dfinies
lors de la premire phase sont rutilises lors de la gnration du mBPI, et que ce dernier
prend correctement en compte les diffrentes modifications effectues sur le diagramme de
processus.
Le Tableau 20 rsume les actions menes et les objectifs recherchs de ces trois phases.
Tableau 20. Rcapitulatifs du droulement et des objectifs du scnario
Phase Droulement Objectifs
1 Transformation Diagramme de processusModule OpenERP Transformation standard BPABPI
2 Modifications fonctionnelles et structurelles du module OpenERP
Transformation Module OpenERPDiagramme de processus
Propagation des modifications (BPI vers BPA)
Intgrit et cohrence des informations
3 Modifications graphiques et structurelles du diagramme de processus
Transformation Diagramme de processus Module OpenERP
Propagation des modifications (BPA vers BPI)
Intgrit et cohrence des informations
A noter que si les objectifs des phases deux et trois sont atteints, alors nous obtenons une
synchronisation ainsi quune quivalence smantique entre m
BPA
et m
BPI
; et donc une cohrence
intermodle.
Ces phases peuvent elles-mmes tre dcomposes en plusieurs tapes. Dans les sections
suivantes, nous dtaillons ces diffrentes tapes. Nous nous attarderons plus particulirement sur la
premire phase. En effet, les mcanismes employs dans la deuxime et la troisime phase sont
essentiellement les mmes que ceux utiliss dans cette premire phase de notre scnario. Nous nous
appuierons sur la Figure 58 qui dtaille les diffrentes tapes de lapproche propose.

REMARQUE
Le scnario dcrit ci-dessus est reprsentatif de lensemble des fonctionnalits de la plateforme SCALP. Mais, il na
pas vocation tre une validation formelle au sens dun projet de dveloppement logiciel.

142 D. MISE EN UVRE

Plateforme SCALP
Diagramme de
processus Intalio
Modle pivot
Module OpenERP

Apport
dinformation
suffisant ?
Diagramme de
processus Intalio
Modle pivot
Module OpenERP

Diagramme de
processus Intalio
Modle pivot
Module OpenERP

Apport
dinformation
ncessaire ?
Aspect
graphique
conserv ?
Modifications dordre technique
(fonctionnelles et structurelles)
Phase (1)
Phase (2)
Phase (3)
Architecte des
processus
Modifications dordre mtier
(graphiques et structurelles)
Figure 64. Scnario de validation

11.3 PREMIERE PHASE : DU DIAGRAMME DE PROCESSUS AU MODULE ERP
Nous considrons que les mtamodles danalyse, dimplmentation et pivot, soit respectivement
MM
BPA
, MM
BPI
et MM
Pivot
, existent et sont dfinis comme nous lavons vu paragraphe 9.7. La premire
phase consiste transformer un diagramme de processus respectant une charte graphique en un
module excutable sous un ERP. La Figure 65 reprend la Figure 58 et met en avant les diffrentes
oprations ralises dans cette premire phase

Figure 65. Droulement de la premire phase
11.3.1 Du diagramme de processus Intalio vers un modle danalyse m
BPA

Nous importons les fichiers XML obtenus partir dIntalio Designer, comme dcrit dans le
paragraphe 10.3, au sein de notre plateforme SCALP.

Plateforme SCALP
Diagramme de
processus Intalio
Fichier logique
(.bpmn)
Fichier graphique
(.bpmn_diagram)
Modle mBPA
(.xmi)
Transformation t1
(intalio2mBPA.java)
Environnement
danalyse
Environnement
pivot
Environnement
danalyse
MMBPA MMBPA MMBPA
MMRep
RefMet
MMRep
RefMet
mPivot
MMRep
RefMet
mBPI
Outil de
modlisation
Progiciel de
gestion
Module
OpenERP
Diagramme
Intalio
mBPA
t1
t4
t2 t3
m1 m3
Figure 66. Du diagramme de processus au modle m
BPA

144 D. MISE EN UVRE

DETAILS TECHNIQUES
Les Figure 67 et Figure 68 montrent respectivement un extrait du fichier logique et du fichier
graphique obtenus laide dIntalio Designer. Il sagit des reprsentations de lactivit Raliser
prlvement du processus tudi.

La transformation t1 est un programme java utilisant le parseur XML JDOM
24
. Cette transformation
cre le modle m
BPA
partir des deux fichiers cits prcdemment. Le modle obtenu est au format .xmi
et est conforme son schma XML, qui correspond ici au mtamodle BPA, le MM
BPA
(le fichier
intalio.ecore) :
xsi : schemaLocat i on="http://ensiacet.org/lgc-psi/bpmn ../../metamodels/BPA/intalio.ecore".
Chaque modle m
i
rencontr durant les diffrentes phases du scnario de validation doit tre
conforme son mtamodle MM
i
associ afin dtre manipulable par Kermeta. Cette conformit est
vrifie laide du menu contextuel propos par Ecore (clic-droit Validate )

24
http://www.jdom.org/
Figure 67. Extrait du fichier logique

Un extrait du modle obtenu est visible Figure 69. Nous y retrouvons lactivit Raliser
prlvement . Un extrait du code source du fichier est disponible en annexe, section 15.4.1. A partir de
ce modle m
BPA
, nous effectuons la transformation t2 afin dobtenir notre modle m
Pivot
.

11.3.2 Du modle danalyse vers le modle pivot
La transformation t2 permettant dobtenir un modle pivot m
Pivot
partir de m
BPA
est un programme
kermeta. Avant dtre ralise, les mappings m1 (MM
BPA
MM
Pivot
) et m2 (MM
Pivot
MM
BPA
) doivent tre
effectus. Le Tableau 21 reprend ces mappings :
Tableau 21. Correspondance smantique entre MM
BPA
et MM
Pivot

Elment MMBPA (A)
Correspondance
smantique
Elment MMPivot (B)
BpmnDiagram
A
S
= B
Process
Pool
A
S
=
B
Pool
Lane
A
S
=
B
Lane
Activity
A
S
=
B
Activity
SubProcess
A
S
=
B
SubProcess
SequenceEdge
A
S
=
B
Edge
Detail
A
S
c B
BPElement

La transformation t2 est effectue en reprenant le paradigme du pattern visiteur (paragraphe
10.5.2). Le fichier Visiteur dtermine les lments (et leurs attributs) appartenant MM
BPA
. Le fichier
transformation les associe aux lments et attributs constituant le MM
Pivot
. La Figure 70 reprsente
lensemble de cette tape et les diffrents fichiers manipuls.

mBPA
(.xmi)
mPivot
(.xmi)
MMBPA
(.ecore)
MMPivot
(.ecore)
Fichier visiteur
(intalioVisitor.kmt)
Fichier
transformation
(.kmt)
Transformation t2
Figure 70. Du m
BPA
au m
Pivot

146 D. MISE EN UVRE

DETAILS TECHNIQUES
Considrons le mapping de llment Activity. Le tableau ci-dessous dfinit les correspondances
existantes entre les diffrents attributs selon quil sagisse dune activit dfinit par le MM
BPA
ou par le
MM
Pivot
.
Nous pouvons constater que de manire gnrale, la dfinition des lments du MM
Pivot
englobe
celles des lments du MM
BPA
. Il en va logiquement de mme entre MM
Pivot
et MM
BPI
. Les informations
concernant laspect graphique de llment Activity sont contenues dans llment BPElement que nous
avons prsent paragraphe 9.5.2. Cet lment permet de conserver les informations non utilises par
lexpert SITI (Figure 71).
Tableau 22. Mapping de llment Activity entre MM
BPA
et MM
Pivot

Elment
MMBPA (A)
Attribut
Elment
MMPivot (B)
Attribut Attribut quivalent
Activity
A
S
c B
Activity

name
A
S
= B

name
iD
A
S
c B
BPElement BPElement:GraphicalAttributes :businessData
activityType
A
S
c B
Node Node:Logical:LogicalType
x
A
S
c B
BPElement BPElement:GraphicalAttributes :CoordinatesType :xCoordinate
y
A
S
c B
BPElement BPElement:GraphicalAttributes :CoordinatesType :yCoordinate
height
A
S
c B
BPElement BPElement:GraphicalAttributes :height

Figure 71. Exemple de m
Pivot


11.3.3 Du modle pivot vers le modle dimplmentation
La transformation t3 possde les mmes mcanismes que la transformation t2. Elle ncessite un
modle XMI en entre, le m
Pivot
, et fournit un modle XMI en sortie, le m
BPI
(Figure 72).

Les quivalences smantiques entre MM
Pivot
et MM
BPI
(mappings m3,m4) sont dfinies Tableau 23.
Tableau 23. Correspondance smantique entre MM
Pivot et
MM
BPI

Elment MMPivot (A) Correspondance smantique Elment MMBPI (B)
Process
B
S
c A
Data
Pool
B
S
c A
Workflow
Lane
A
S
B
*
Activity
B
S
c A
Activity
SubProcess
B
S
c A
Activity
Edge
B
S
c A
Transition

* : Llment Lane nexiste pas en tant que tel dans un modle mBPI. Cependant, son attribut
name dfinit lattribut role_id de llment Transition. Concrtement, lors de lexcution du module, seule
une catgorie dutilisateurs reconnue ou disposant des mmes droits que la catgorie role_id pourra
valider une transition possdant lattribut role_id.
La Figure 73 montre un extrait du m
BPI
obtenu, un extrait du code source est fourni en annexe,
section15.4.2.
MPivot
(.xmi)
MBPI
(.xmi)
MMPivot
(.ecore)
MMBPI
(.ecore)
Fichier visiteur
(pivotVisitor.kmt)
Fichier
transformation
(mPivot2mBPI.kmt)
Transformation t3
Figure 72. Du m
Pivot
au m
BPI

Figure 73. Extrait de m
BPI

Plateforme SCALP
Module OpenERP
MBPI
(.xmi)
_init_.java
_terp_.java
MainFunctions.java
XMLView.java
XMLWorkflow.java
Transformation t4
_init_.py
_terp_.py
nomModule.py
nomModuleView.xml
nomModuleWorkflow.xml
Figure 74. Du m
BPI
au module OpenERP

11.4 DEUXIEME PHASE : DU MODULE ERP AU DIAGRAMME DE PROCESSUS
Le module OpenERP obtenu ltape prcdente nest pas utilisable en ltat. Les fichiers
nomModule.py et nomModuleView.xml demandent un apport dinformation afin dtre utilisables. A cet
effet, les fichiers sont amens tre modifis par lexpert SITI. La Figure 75 reprsente les principaux
mcanismes mis en uvre au cours de cette phase afin dobtenir un diagramme de processus partir
des fichiers du module OpenERP.

Figure 75. Droulement de la seconde phase
11.4.1 Modifications apportes
Le fichier nomModule.py dcrit la vue fonctionnelle de notre processus, des fonctions logiques
exprimes en langage python sont y ajoutes. Ces fonctions reprsentent les actions ralises par les
diffrentes activits du processus de rintgration. Par exemple, nous dsirons ajouter une fonctionnalit
valuant le temps effectif pass sur un lot cibl (Figure 76).

Nous effectuons galement des modifications de type structurel. Pour cette partie du scnario,
nous simulons lajout dune activit permettant de mettre jour la liste des lots de produits semi-finis
utiliss dans le processus de rintgration. Cette modification se traduit par une (modification du control-
flow de par lajout de lactivit et des changements au niveau du squencement. Les fichiers
nomModule.py et nomModule_workflow.xml sont modifis en consquence laide de lditeur
dOpenERP.
Environnement
danalyse
Environnement
pivot
Environnement
danalyse
MMBPA MMBPA MMBPA
MMRep
RefMet
MMRep
RefMet
mPivot
MMRep
RefMet
mBPI
Outil de
modlisation
Progiciel de
gestion
Module
OpenERP
Diagramme
Intalio
mBPA
t1
t4
t6 t5
m2 m4
Figure 76. Fonction python extraite du fichier nomModule.py
150 D. MISE EN UVRE

REMARQUE : INTERFACE DU MODULE OPENERP
Le fichier nomModuleView.xml dfinit linterface utilisateur du processus. Il est vident que lors de la modlisation du
processus laide de loutil Intalio Designer, lanalyste mtier na pas fourni dinformations spcifiques quant sa
reprsentation et sa manipulation sous le progiciel OpenERP. Le dveloppement dune telle interface ne rentre pas
dans le cadre de notre dmonstration. Il est donc la charge de lexpert SITI de dvelopper une interface
ergonomique. Pour cela, il doit utiliser de manire adquate les informations contenues dans les autres fichiers du
module OpenERP et se baser sur la structure offerte par le fichier nomModuleView.xml. A titre dillustration, la Figure
77 reprsente un exemple dinterface pure possible et dvelopp pour lexemple.

11.4.2 Du module OpenERP vers le modle dimplmentation
La transformation t4 est un programme java se dcomposant en trois tapes bien distinctes. Une
premire tape consiste parcourir les diffrents fichiers python et relever les informations ncessaires
au m
BPI
. De mme la deuxime tape utilise le parseur XML JDOM sur les fichiers XML du module
OpenERP. Enfin, cette transformation se termine par la cration dun modle m
BPI
, galement ralise
laide du parseur XML JDOM. Le modle obtenu est au format .xmi et est conforme son schma XML,
qui correspond au mtamodle BPI, le MM
BPI
. La Figure 78 retrace le droulement de cette
transformation.
Figure 77. Exemple dinterface pour le module Processus de rintgration sous OpenERP

DETAILS TECHNIQUES
Les fonctionnalits ajoutes au fichier nomModule.py dfinissent les actions ralises par les
activits. Lors de la transformation t4, les diffrentes modifications forment lattribut Action de llment
Activity auquel elles sont assignes.

Les informations apportes au fichier nomModuleView.xml ne sont pas prises en compte : nous ne
considrons pas la dfinition de linterface utilisateur comme ncessaire la bonne comprhension du
processus tudi.

11.4.3 Du modle dimplmentation au diagramme de processus
Les transformations t5 et t6 permettent respectivement dobtenir m
Pivot
partir de m
BPI
et m
BPA

partir dudit m
Pivot
. Ces transformations se ralisent de la mme manire que les transformations t2 et t3 :
- laide du langage Kermeta ;
- et en utilisant le paradigme du pattern visiteur.
Plateforme SCALP
mBPI
(.xmi)
Module OpenERP
_init_.py
_terp_.py
nomModule.py
nomModuleView.xml
nomModuleWorkflow.xml
Lecture des
fichiers .xml
Lecture des
fichiers .py
Construction
du modle
.xmi
Transformation t4
Figure 78. Du module OpenERP au le m
BPI

Figure 79. Extrait du m
BPI
modifi
152 D. MISE EN UVRE

Cependant, deux diffrences notables sont signaler. Tout dabord, lors de la transformation t5,
nous apportons des informations supplmentaires concernant le modle de processus. Ces informations,
issues de la plateforme dimplmentation sont notifies travers le sous-lment ImplAttributes de
llment BPElement. Ds lors, en rcuprant les donnes contenues dans le sous-lment
GraphicalAttributes du m
Pivot
prcdent, nous gnrons un modle pivot contenant la fois les donnes
spcifiques au m
BPA
et au m
BPI
. Afin dviter toutes ambigits, le modle pivot gnr est appel m
Pivot
2

(Figure 80).

Puis, lors de la transformation t6, nous utilisons les donnes contenues dans BPElement afin de
gnrer un modle danalyse possdant les mmes informations graphiques que le mBPA gnr lors de
la premire phase. Comme prcdemment, pour viter toutes ambiguts, le modle obtenu est nomm
m
BPA
2
(Figure 81).

Pour finir, la transformation t1 permet de transformer le modle danalyse obtenu durant cette
deuxime phase en un diagramme de processus. Pour cela, nous utilisons un programme java utilisant le
parseur XML JDOM. Ce programme gnre les deux fichiers ncessaires loutil Intalio Designer pour
reprsenter un processus : un fichier logique et un fichier graphique (Figure 82).
mBPI
(.xmi
)
mPivot
(.xmi)
mPivot
2

(.xmi)
MMBPI
(.ecore) MMPivot
(.ecore)
Fichier visiteur
(openERPVisitor.kmt)
Fichier
transformation
(mBPI2mPivot.kmt)
Transformation t5
BPElement
GraphicalAttributes
Extraction
Ajout
Gnration
Figure 80. Du m
BPI
au m
Pivot

mPivot
2

(.xmi)
mBPA
2

(.xmi)
MMPivot
(.ecore)
MMBPA
(.ecore)
Fichier visiteur
(pivotVisitor.kmt)
Fichier
transformation
(mPivot2mBPA.kmt)
Transformation t6
Figure 81. Du m
Pivot
au m
BPA


DETAILS TECHNIQUES
Si lors de cette deuxime phase, les modifications apportes ne concernaient que les
fonctionnalits des activits du processus (autrement dit leur excution sous OpenERP) et lapparence
du module OpenERP, le diagramme de processus obtenu est identique celui utilis lors de la premire
phase.
Cependant, des modifications portant sur lorchestration desdites activits peuvent tre effectues
au dbut de la deuxime phase par lexpert SITI. Considrons, titre dexemple, lajout de lactivit
Mettre la liste jour , activit suivant lactivit Traiter les produits semi-finis et prcdant lactivit
Traiter en interne . Lors de la gnration du modle pivot, les attributs graphiques de cet lment ont
une valeur par dfaut ( 0 , null ou empty selon les cas). Ces donnes sont visibles sur la Figure
83, reprsentant le fichier graphique rsultant de la transformation t1.

Figure 82. Du m
BPA
au diagramme de processus
Figure 83. Extrait du fichier graphique obtenu
Plateforme SCALP
mBPA
2

(.xmi)
Transformation t1
(intalio2mBPA.java)
Fichier logique
(modeler.bpmn)
Fichier graphique
(modeler.bpmn_diagram)
Diagramme de
processus Intalio
154 D. MISE EN UVRE

La Figure 84 montre la reprsentation de processus correspondante, avec lactivit situe
lorigine du diagramme (avec ses coordonnes x=0 et y=0).

Ce diagramme est reprsente en intgralit en annexes, section15.4.4.

REMARQUE : UTILISER LES FICHIERS LOGIQUE ET GRAPHIQUE AU SEIN DINTALIO DESIGNER
Par dfaut, Intalio Designer ne possde pas de fonctionnalits permettant dutiliser les fichiers logique et
graphique crs par un diteur tiers. Pour obtenir un diagramme de processus dcoulant de ces deux fichiers, il
faut effectuer la manipulation suivante :
- Crer un nouveau diagramme de processus vierge sous Intalio Designer ;
- Crer les sources comme expliquer paragraphe 10.3 ;
Remplacer ces sources par nos fichiers logique et graphique , modeler.bpmn et modeler.bpmn_diagram.

11.5 TROISIEME PHASE : DU DIAGRAMME DE PROCESSUS AU MODULE ERP
Considrons maintenant la troisime phase. Nous supposons que durant cette phase, lanalyste
mtier apporte des modifications au diagramme de processus et que nous disposons dun modle pivot
contenant des informations relatives aux divers lments composant le modle de processus. Nous ne
re-dtaillons pas les tapes de la transformation permettant dobtenir un module OpenERP partir dun
diagramme de processus ralis sous Intalio Designer. Ces tapes sont dtailles lors de la dfinition de
la premire phase. Le droulement de cette troisime phase reprend en effet celui de la premire phase,
reprsent par la Figure 65. Nanmoins, le rsultat de cette transformation est variable. En effet, elle
dpend des modifications effectues sur le diagramme de processus.
- Modifications graphiques : lanalyste mtier r-agence les diffrents lments du
diagramme. Par exemple, il aligne les activits Mettre la liste jour , Traiter les produits semi-
finis et Traiter en interne . A laide du modle pivot, les fichiers constituant le module
OpenERP sont gnrs automatiquement. Le fichier monModuleView.xml reste inchang.
Figure 84. Extrait du diagramme de processus obtenu

- Modifications ponctuelles : lanalyste mtier ajoute, supprime, modifie le squencement dun
ou plusieurs lments de type nud. Par exemple, il ajoute un acteur, le Responsable de Ligne,
au processus, lui rattribue lactivit Rceptionner le lot et ajoute ensuite une activit Archiver
les donnes du lot . Lors de la constitution du module OpenERP, seules les fonctionnalits lies
aux nouveaux lments (comme lactivit Archiver les donnes du lot ) sont dfinir et celles
lies aux lments modifis (comme lactivit Receptionner le lot ) sont redfinir, ainsi que les
transitions adjacentes ces lments. Le fichier monModuleView.xml reste inchang.
Les diffrentes modifications ralises sont reprsentes sur la Figure 100, dans les annexes,
section 15.4.5.
11.6 CONCLUSION
Le scnario bas sur un processus issu de lindustrie cosmtique permet de valider notre approche
et la plateforme SCALP rsultant de notre projet de dveloppement logiciel.
Lors de la premire phase, nous avons ralis la transformation dun modle conceptuel, un
diagramme de processus, en un modle technique, un module ERP. A chaque tape de cette
transformation, la conformit entre le modle xmi obtenu et son mtamodle est valide laide dEcore.
Durant cette phase, nous avons pu montrer comment nous stockons les donnes non-utilisables par le
modle technique laide du modle pivot. Ces donnes sont restitues lors de la seconde phase
permettant dobtenir un modle conceptuel complet. Et comme prcdemment, les donnes non-
utilisables par le modle conceptuel sont stockes par le modle pivot. La troisime phase montre
galement que le modle technique ne ncessite pas dapport dinformation si les modifications
effectues sur le modle conceptuel ne sont que dordre graphique.
A travers les diffrentes transformations, nous gnrons un modle de sortie prenant directement
en compte les modifications subies par le modle dentre (par exemple la cration dune activit) ou
indirectement (modifications des instructions python associes une activit). Nos deux modles sont
donc synchroniss comme dfini paragraphe 7.1.1. Dans les deux cas, les donnes sont retranscrites au
sein du modle pivot. Les mtamodles associs aux modles danalyse et dimplmentation dcoulent
du mtamodle pivot. Les diffrents lments dun mtamodle possdent leurs quivalents, comme
nous lavons montr laide des diffrents mappings spcifiant notre approche. Par ailleurs, comme nous
lavons indiqu, nos modles restent synchroniss. Ils sont donc smantiquement quivalents
(paragraphe 7.1.2).
Ces trois phases dmontrent lutilit de notre approche. Elle transforme des modles htrognes
et dabstractions diffrentes, tout en stockant et ajoutant des donnes ncessaires lors du passage BPA-
BPI et inversement. Les modifications tant propages lors de ces transformations et lintgrit des
informations tant assure, notre approche permet une synchronisation et une quivalence smantique
des modles. Nous obtenons alors une cohrence intermodle telle que dfinie chapitre 7.1.3.

12. Ingnierie des processus au service de
lingnierie des procds
(Debauche & Megard 2004) : Deux termes sont souvent utiliss pour dsigner une dfinition ou
un modle de processus : procdure , qui sapplique davantage des processus impliquant des
personnes et de limmatriel (procdure bancaire, procdure budgtaire, procdure de justice, etc.) ;
procd , plutt utilis dans la fabrication de produits partir de matires premires .
Dans ce chapitre nous essayons de dterminer la corrlation existante entre processus et procd.
Pour cela, nous adoptons un point de vue structurel, o nous cherchons tablir les liens existants entre
les diffrents modles de processus et de procds. Puis nous nous situons selon un point de vue
smantique et dfinissons les liens existants entre ontologies de domaines, et rgles mtiers.

C
H
A
P
I
T
R
E

12
158 MISE EN UVRE

12.1 NOTIONS AUTOUR DE LINGENIERIE DES PROCEDES
Lingnierie des procds (Process Systems Engineering- PSE) est une discipline mature qui a volu
au fil du temps au sein de diffrents champs de recherche : le gnie chimique, les mathmatiques
appliques, linformatique et le gnie logiciel. Dans ce chapitre nous tudions la partie informatique/ gnie
logiciel avec notamment les outils et les mthodes dirigs par les modles. Linformatique (au sens PSE)
doit concilier la complexit inhrente dun procd avec la nature multi-objectif de la prise de dcision
durant le cycle de vie dudit procd. Afin daccomplir cette tche, des outils et des mthodes bass sur
des modles phnomnologiques ont t dvelopps. Les notions de contrle et de production des
procds bass sur des modles ne sont pas nouvelles (Edgar 2004). De mme, la notion dentreprise
vue dans sa globalit ou encore la notion de gestion de sa chane logistique sont au cur de nombreux
travaux (Grossmann 2004), (Varma et al. 2007).
Ltude propose par (American Chemical Society et al. 1996) identifie quatre disciplines
techniques comme tant de futurs acteurs majeurs dans le dveloppement de lingnierie des procds
physico-chimiques :
- Les nouvelles sciences chimiques (synthse chimique, technologie des matriaux, ) et
technologies dingnierie (mesures chimiques, science du procd,) ;
- La gestion de la chane logistique ;
- Lindustrie et les oprations (capacit de production, construction de sites, contrle des
procds et des informations) ;
- Et les systmes dinformation.
Selon (Schneider and Marquardt 2002) la discipline lie aux technologies de linformation a
longtemps t traite dun point de vue approvisionnement, fabrication et distribution de produits et
matriaux . Depuis, plusieurs auteurs ont voqu lintrt dutiliser des techniques de modlisation de
processus mtier. Toutefois, la conception des procds laide de mthodes de modlisation comme
CLiP (Bayer et al. 2001) ou plus rcemment IDEF0 (National Institute of Standards and Technology
(NIST) 1993), (Hirao et al. 2008), ne permet pas lassociation des diffrents concepts lis au procd
avec ceux de lentreprise. Au contraire, nous pensons quune approche top-down , depuis lentreprise
vers le procd, est possible. Une telle dmarche permettrait de mettre en adquation les objectifs mtier
dune entreprise et ceux induis par la mise en uvre dun procd bio-physico-chimique, quel que soit
son type (continu ou batch), (statique ou dynamique).
Dans ce chapitre, nous nous concentrons sur la conception des procds avec le support des
concepts, mthodes et outils de lIngnierie des Entreprises et des Systmes dInformation (IESI). Nous
exposons en ltat nos rflexions sur les termes de processus et procds. Nous cherchons notamment
dterminer comment coupler lingnierie des processus avec lingnierie des procds et les bnfices
que nous pourrions obtenir. En particulier, nous analysons et dterminons de quelle manire lIDM et les
technologies de linformation peuvent influencer le cycle de vie des procds.
Ontologie et ontologie domaine
Toute activit humaine spcialise dveloppe un langage ayant un vocabulaire propre sa
spcialit. Lexistence de tels langages entrane des problmes de comprhension et des difficults
12. INGENIERIE DES PROCESSUS AU SERVICE DE LINGENIERIE DES PROCEDES 159

partager des connaissances entre les acteurs dune entreprise, les services dune entreprise, les
entreprises dun mme groupe, faisant des mtiers diffrents. Le rle des ontologies est damliorer la
communication entre acteurs humains puis entre humains et ordinateurs et finalement entre ordinateurs.
Selon (Uschold and Gruninger 1996), une ontologie peut prendre diffrentes formes, mais elle
inclura ncessairement un vocabulaire de termes et une spcification de leur signification. Cette dernire
inclut des dfinitions et une indication sur la faon dont les concepts sont relis entre eux, les liens
imposant collectivement une structure sur le domaine et contraignant les interprtations possibles des
termes . Plus prcisment, (Gruber 1993) une ontologie est une spcification de conceptualisation. La
thse de (Izza 2006) traite plus en profondeur la notion dontologie, sa construction et son usage pour les
SI.
A travers nos travaux, nous nous sommes intresss en particulier la notion dontologie de
domaine. Les ontologies de domaine sont des ontologies construites sur un domaine particulier de
connaissance (Guarino 1998), (Izza 2006). Elles dcrivent le vocabulaire reli ce domaine, en
particulier ses concepts, les relations existantes entre ceux-ci, les activits propres ce domaine et les
thories le rgissant. Plusieurs ontologies de domaine propres lingnierie des procds ont t
dveloppes comme VeDa, PML/GML (Bayer and Marquardt 2003) ou plus rcemment OntoCAPE
(Marquardt et al. 2010) dont les concepts-cls sont reprsents sur la Figure 85.

Figure 85. Concepts-cls dOntoCAPE pour la modlisation de procd (Yang et al. 2008)
12.2 VERS UNE APPROCHE PROCESSUS-PROCEDE
Comme nous lavons nonc prcdemment le PSE sintresse aux mthodes et outils daide la
dcision sarticulant autour des procds. Ces mthodes doivent en particulier tre en mesure de
planifier, concevoir, rendre oprationnel et contrler tous types doprations unitaires, de procds et leur
production (Takamatsu 1983). La modlisation assiste par ordinateur pour la conception de procd ou
Computer-Aided Modelling and Process Design, se base sur la modlisation du cycle de vie du procd et
ChemicalProcessMaterial
PropertyModel
Model
Physicochemical
Phenomenon
Law
ChemicalProcessSystem
n
n
n
n
n
1
1
1
1
1
n
is_materialized_by
has_property
models
has_property
models
has_phenomenon
160 MISE EN UVRE

exploite fortement les technologies de linformation (Schneider & Marquardt 2002). Selon (Bayer,
Weidenhaupt, Jarke, & Marquardt 2001) ce cycle de vie se dcompose en sept tapes.
Tout dabord une tape dexploration durant laquelle nous exprimons les besoins, les
caractristiques techniques gnrales du procd et les divers paramtres (conomiques,
environnementaux,) sarticulant autour de celui-ci. Sensuit une tape de recherche et dveloppement.
Une recherche de la chimie est effectue puis la dfinition de nouvelles techniques et modles
mathmatiques sont amenes tre amliors. Cest lissue de cette tape quest produit le
diagramme de procd prliminaire, ou Block-Flow Diagram - BFD. Ltape suivante, la conception
fonctionnelle, rend la vision du procd plus concrte. Une tude des aspects structurels est ralise puis
nous valuons un ou plusieurs procds conceptuels ainsi que les alternatives de conception associes.
De cette tape rsulte le diagramme de procd fonctionnel, ou Process-FlowSheet - PFS. Lors de ltape
de conception dtaille, ce PFS est transform en un plan de procds, Piping and Instrumentation Diagram,
o figurent tous les quipements et leur caractrisation. Les tapes de construction, exploitation et
dmantlement sintressent plus particulirement au(x) site(s) gographique(s) o les procds seront
mis en uvre. La figure 10 montre ces sept tapes et ainsi que les quatre grandes familles doutils-
CAPE : Simulation pour lanalyse et la conception, Simulation pour la formation et la validation des
systmes de contrle, Optimisation hors-ligne et en ligne, et Contrle avanc.
Nous pensons que le BPM et en particulier la phase BPA peuvent intervenir en amont de ce cycle
de vie et ainsi sinscrire au sein des trois premires tapes du cycle (Figure 86).

Formaliser les relations existantes entre le niveau processus et le niveau procd de lentreprise
permet de considrer le procd sous diffrents aspects de reprsentation et ainsi contribuer une vue
plus complte du procd. En effet, selon (Klatt and Marquardt 2009), adopter une dmarche multi-vue et
travers diffrentes chelles de rsolution chimique, spatiale et temporelle est recommand pour
amener la conception (du procd) un vrai optimum . En termes de modles, le diagramme de
processus dentreprise ou Business Process Diagram BPD, se situe en amont dun BFD (Figure 87), un BPD
est un modle pouvant essentiellement dcrire une entreprise selon un point de vue fonctionnel.

Exploration R&D Conception
fonctionnelle

Conception
dtaille

Construction

Exploitation

Dmantlement

Simulation pour la formation et la
validation des systmes de contrle
Contrle avanc
Cycle de vie
BPA
Simulation pour lanalyse et la
conception
Optimisation hors-ligne et en ligne
Figure 86. Dcoupage du PSE (Belaud 2002) et influence potentielle du BPA sur le cycle de vie du procd

Dans les paragraphes suivants nous proposons de dfinir les relations existantes entre lingnierie
des processus, le gnie industriel et le gnie des procds selon un point de vue structurel (logique).
Puis nous dfinissons les liens smantiques pouvant exister entre leurs modles respectifs.

Un Block-FlowDiagramest dfini comme tant une reprsentation gnralement labore pour dfinir
un ou plusieurs procds et units de productions. Sur ce diagramme peuvent figurer les bilans de
matires globaux dune installation, ainsi que les bilans des charges et produits passant dune unit de
production une autre. Cette reprsentation peut galement dcrire les besoins en stockage et de
rception/expdition des diffrents flux (de procds et/ou dutilits). Ds lors, nous pouvons assimiler les
lments modliss par un BFD comme une activit de type sous-processus au sein dun processus
mtier. Effectivement, selon (Godart and Perrin 2009) une activit est une description dun fragment de
travail qui constitue une tape logique lintrieur dun processus. Les actions ralises par une activit
peuvent tre manuelles ou automatiques. Pour sexcuter, une activit utilise des ressources humaines
et/ou des quipements. Si nous pouvons dcomposer cette activit en plusieurs activits alors il sagit
dune activit de type sous-processus. Un sous-processus est forcment appel et initialis par le
processus global dont il fait partie. Plusieurs niveaux dabstraction dimbrication de processus peuvent
tre supports.
Nous obtenons les relations suivantes reprsentes sur la Figure 88 :
- Une entreprise peut tre reprsente par un ou plusieurs processus ;
- Un processus peut tre compos dun ou plusieurs sous-processus, certains de ces sous-
processus pouvant tre dcrits par des BFD ;
Molcules
Particules
Units de
procds
Ateliers
Site
industriel
Entreprise
Gnie
industriel
Ingnierie des
procds
Ingnierie des
processus
Echelle de taille
BPD
BFD
PFS
Relations
existantes ?
Echelle de temps
Relations
existantes ?
Figure 87. BPD, BFD, PFS partir du Chemical Supply-Chain (Marquardt et al. 1999)
162 MISE EN UVRE

- Un sous-processus dcrit par un BFD peut tre reprsent par un ou plusieurs diagrammes
de procd fonctionnels.

Ainsi, nous pouvons reprsenter le BFD lors de la modlisation dun processus, comme par
exemple dans la Figure 89, o le BFD est dcrit par un sous-processus et dont le dtail rvle celui-ci. La
recherche dquivalences entre les lments de modlisation dun BPD et dun BFD est dailleurs en
cours dtude.

Figure 89. Approche multi-chelle Processus-Procd (sous format BPMN)
Comme dfinis dans la section prcdente, une ontologie de domaine pour systme de procds
sert de source de concepts et permet de construire un modle de procd conceptuel. Dans lingnierie
des processus, nous utiliserons la notion de gestion de rgles mtier ou Business Rules Management BRM.
Daprs le Business Rules Group
25
(The Business Rules Group (BRG) 2007), une rgle mtier est une
directive, destine rgir, contrler ou influencer le comportement mtier dune entreprise. Les rgles
mtier sappliquent aux processus mais sont modlises indpendamment du modle logique. Nous
considrons ces rgles comme tant similaires des rgles dontologie de domaine. En effet, les rgles
mtier comme lontologie de domaine sont drives dontologies de plus haut niveau (Figure 90).

25
http://www.businessrulesgroup.org/
Processus
Sous-processus, Block-flow
Procd, Process-flow

Entreprise
1
*
1
*
1
*
Figure 88. Cardinalits entre entreprise, processus, sous-processus et procd

La recherche dquivalences smantiques entre les concepts des rgles mtier et dontologies de
domaine type-procd aurait pour consquence :
- de transmettre les contraintes dtermines lors de lanalyse dun processus au modle
conceptuel de procd (ici le BFD) ;
- et ainsi damliorer ladquation entre objectifs mtier et conception du procd ;
- afin dobtenir un modle multi-chelle processus/procd cohrent ;
- de structurer et de formaliser via modles, mtamodles et ontologies les approches top-down
et bottom-up.
12.3 CONCLUSION
Considrer la dimension mtier apporte par lingnierie des processus mtier lors de la phase
danalyse du cycle de vie du procd est une perspective intressante dun point de vue logique ainsi que
dun point de vue smantique. Nous avons dmontr la possibilit dinclure un diagramme de procds
prliminaire (BFD) au sein dun modle de processus (BPD). Nanmoins, il faut encore dfinir
formellement les diffrents lments permettant de modliser un BFD au sein de ce BPD. Cette approche
verticale de lanalyse des processus et procds doit tre ralise avec le soutien dontologies.
Formaliser les relations smantiques existantes entre les diffrents concepts lis au procd avec ceux
lis au processus sera le sujet de travaux futurs.
Le choix des diffrents niveaux dabstraction assurant la cohrence multicouches des trois
modles appartient lquipe de modlisation. Nanmoins, au-del de lactivit de modlisation des
diffrents concepts et des bnfices connus qui en rsultent, lingnierie des procds ncessite
traditionnellement une activit de simulation lors de la phase conception fonctionnelle . Or si nous
tenons compte des outils actuels de simulation du champ de lingnierie des systmes de procds
(PSE), le niveau de granularit du schma de principe de procd (PFS) simpose nous travers le
primtre dune opration unitaire (unit operation).
Coupl notre approche BPM, le PFS pourrait donc se traduire par un fichier de donnes pour un
simulateur PSE type ProSimPlus. Ce fichier reprsentant le modle Procd serait alors en cohrence
avec le modle Processus. Ainsi lalignement des diffrents modles multi-chelles de lentreprise serait
permis. Pour raliser cet alignement, une approche telle que celle prsente dans ce manuscrit peut tre
Ontologie A
Ontologie de
domaine
Ontologie B
Rgles mtier
Mapping
smantique ?
Mapping
smantique ?
Figure 90. Equivalences smantiques possibles entre ontologie de domaine et rgles mtier ?
164 MISE EN UVRE

utilise. Il sera possible dappliquer notre mthode pivot de manire pouvoir gnrer depuis un BPD, un
fichier de simulation type ProSimPlus (Figure 91).

Aussi, une telle approche pourrait sappliquer au-del du primtre dune seule entreprise. Le
systme global tudier serait donc interentreprise. Cet aspect-l est hors de notre champ dtude
actuellement. Notons cependant que les travaux issus de linteroprabilit des entreprises (Vernadat
2007) peuvent nous apporter des solutions au niveau Processus (hub dentreprises, processus public-
priv, architectures orientes services, UEML
26
, ). Il resterait investiguer le niveau Procd, tout en
conservant lalignement et la cohrence smantique des modles, non seulement dun point de vue multi-
chelle mais galement interentreprise.

26
Unified Enterprise Modeling Language, (Anaya, Berio, Harzallah, Heymans, Matulevicius, Opdahl, Panetto, & Verdecho 2008)
Simulateur PSE
Outil de modlisation
Plateforme pivot
Modle pivot
Environnement danalyse
Modle
danalyse
(BPD +BFD)
Environnement
dimplmentation
Modle de
procds
(PFS)
Ontologie
Rgles mtier Ontologies de
domaine
Processus/procd
tudi
Fichier de
simulation
ProSim obtenu
Figure 91. Approche pivot pour la gnration dun PFS partir dun BPD

CINQUIEME PARTIE
E. EPILOGUE
13. Conclusion et Perspectives .. 167
14. Bibliographie .. 175
15. Annexes .. 185

166 EPILOGUE

RESUME
Cette dernire partie comprend une conclusion gnrale. Nous prsentons galement un bilan de
nos travaux ainsi que les contributions ralises travers notre approche et la plateforme SCALP. Nous
discutons des limites et des perspectives lies la poursuite de ces travaux selon dun point de vue
conceptuel et selon un point de vue technique.
Cette partie sachve par la bibliographie utilise dans le manuscrit et les diffrentes annexes.

13. Conclusion et Perspectives
13.1 CONCLUSION
Nos travaux de recherche abordent une approche gnrique pour la modlisation et
limplmentation des processus. Cette approche cherche caractriser la notion dalignement au niveau
oprationnel et maintenir la cohrence entre les modles issus des environnements danalyse et
dimplmentation, la synchronisation entre ces modles et leur quivalence smantique.
Pour cela, notre approche adopte une dmarche dingnierie des processus mtier (BPM). Son
objectif principal est de rduire lcart existant entre lenvironnement danalyse (domaine mtier) et
lenvironnement dimplmentation (domaine Systmes dInformation et des Technologies
dInformation - SITI). Cette approche se base sur un lment pivot garantissant la prservation et
lintgrit des informations des modles manipuls et appartenant des domaines diffrents. Pour cela,
un dialogue entre les acteurs des diffrents environnements (lanalyste mtier et lexpert SITI) doit
seffectuer et tre supervis. Ce rle incombe larchitecte des processus que nous avons dfini dans ce
manuscrit. Notre approche permet ainsi de :
C
H
A
P
I
T
R
E

13
168 EPILOGUE

- Garantir une cohrence intermodle entre modles htrognes et dabstractions
diffrentes, grce aux mcanismes de transformations de modles bass sur des mtamodles
formellement dfinis et lutilisation dun modle pivot ;
- Dentretenir un couplage faible entre environnement danalyse et environnement
dimplmentation.
Pour dmontrer la faisabilit de cette approche, un prototype logiciel a t dvelopp en ce sens,
la plateforme SCALP (Solution pour une Cohrence et un Alignement des Processus). Cette plateforme
repose sur des technologies logicielles issues de lopen source et ne possdant pas de compatibilit
particulire. La mise en uvre de cette plateforme nous permet dobtenir une transformation bilatrale
entre modles htrognes et une cohrence intermodle.
13.2 BILAN
Pour synthtiser les contributions apportes par nos travaux de recherche, nous reprenons chaque
partie du document et rsumons les contributions associes.
13.2.1 Cadre mthodologique
De ltat de lart abord dans cette partie, nous avons tudi les relations existantes entre
lentreprise et les processus quelle met en uvre, ainsi que les notions accompagnant la manipulation
de ces processus par leurs modles. Nous avons effectivement dmontr que le processus se situe au
cur de la vue fonctionnelle de lentreprise, cette vue se situant elle-mme au centre des vues
dfinissant lentreprise. Une approche centre processus permet damliorer lagilit de lentreprise. La
notion de processus nest pas rvolutionnaire en soi, cependant grer compltement son cycle de vie
demeure un exercice difficile. La prsence dacteurs diffrents intervenant sur les reprsentations de
processus et lutilisation de modles htrognes et dabstractions diffrentes contribuent la cration
dun non-alignement oprationnel entre les domaines mtier et SITI, cart se creusant durant le cycle de
vie du processus. Pour tenter dy remdier, des paradigmes et outils portant sur lutilisation et la
manipulation des modles desdits processus, en particulier lingnierie des processus mtier et
lutilisation de suites BPM, sont dvelopps et mis en uvre. Malgr cela, le lien entre lenvironnement
danalyse (domaine mtier) et lenvironnement dimplmentation (domaine SITI) reste difficile maintenir.
Rduire lcart entre domaines mtier et SITI et donc amliorer lalignement oprationnel est lobjectif de
nos travaux de doctorat.
13.2.2 Dfinition de lapproche
Des limites dune dmarche BPM standard , nous identifions trois conditions ncessaires
lalignement oprationnel, rduisant par la mme occasion lcart mtier-SITI : (i) la synchronisation, (ii)
lquivalence smantique et (iii) la cohrence entre les modles danalyse et les modles
dimplmentation correspondants. Nous mettons galement en avant des notions ncessaires une
gestion agile des processus dentreprise, savoir lutilisation de rgles mtier, la volont dobtenir un
couplage faible entre environnements danalyse et dimplmentation et lutilisation systmatique de
mtamodles pour la transformation de modles. Essentiellement base sur la vue fonctionnelle,
13. CONCLUSION ET PERSPECTIVES 169

lapproche pivot que nous proposons assure un couplage faible entre environnements danalyse et
dimplmentation, tout en maintenant la cohrence entre les diffrents modles et mtamodles. Dune
gnricit que nous avons qualifie de relative , lapproche reste indpendante des langages et des
environnements utiliss. Sa mise en uvre ncessite lintervention dacteurs divers : lanalyste mtier et
lexpert SITI. Nanmoins nous avons dfini un troisime rle comme tant un intermdiaire ncessaire au
bon droulement de lapproche : larchitecte de processus.
Bass sur notre tude de la littrature, nous proposons un mtamodle pivot permettant la
ralisation de notre approche. Ce mtamodle sappuie sur les concepts usuels utiliss pour la
reprsentation des processus et respecte la classe de conformit simple des lments dXPDL propose
par WfMC. Nous proposons galement des outils permettant la cration et la dtermination des relations
smantiques pouvant exister entre mtamodle pivot, mtamodle issu de lenvironnement danalyse et
celui issu de lenvironnement dimplmentation. Nous dfinissons galement les fonctions de conformit
constructive assurant la transformation dun modle vers un autre, chacun respectant au final le
mtamodle qui lui est associ.
13.2.3 Mise en uvre
Afin de valider nos diffrentes propositions exposes au long de ce manuscrit, nous prsentons un
prototype logiciel mettant en uvre et validant notre approche, la plateforme Solution pour un
ALignement et une Cohrence entre Processus, SCALP, plateforme reposant sur EMF et Kermeta.
Lobjectif de ce prototype est de montrer lintrt de notre approche en transformant un diagramme de
processus reprsent laide de lditeur Intalio Designer en un module exploitable par le progiciel de
gestion intgr OpenERP. Ainsi, notre plateforme sappuie sur des applications logicielles sans
compatibilit particulire et fournissant des modles htrognes et dont les environnements danalyse et
dimplmentation ne proposent pas de mtamodles au sens strict.
Ltude de cas ralise porte sur un processus de rintgration de produits type parfum ayant subi
un contrle qualit. Ce processus a t rcemment mis en place par un grand groupe de cosmtique au
sein de ses units de production de parfum. Nous illustrons lutilisation de la plateforme SCALP travers
un scnario constitu de trois phases. Lors de la premire phase, nous ralisons la transformation dun
modle conceptuel, un diagramme de processus, en un modle technique, un module ERP. Cette phase
montre comment SCALP ralise la transformation tout en prservant les donnes issues du modle
danalyse et non-utilises par le modle dimplmentation travers le modle pivot. Le module obtenu
ncessite des ajustements manuels. Lors de la seconde phase, SCALP permet de prserver leur tour
les informations issues du modle dimplmentation, tout en restituant les informations ncessaires au
modle danalyse. Nous prouvons galement que les modifications effectues entre ces deux phases
sont bien prises en compte. La troisime phase du scnario montre que les modifications apportes au
modle danalyse, SCALP est en mesure de fournir directement un module OpenERP complet et ne
ncessitant pas dapport dinformation, laide du modle pivot. En synthse, nous observons que
SCALP gnre un modle de sortie prenant directement ou indirectement en compte les modifications
subies par le modle dentre. Et laide dun modle pivot, lintgrit des informations est assure. Ainsi
170 EPILOGUE

SCALP permet une synchronisation et une quivalence smantique des modles. Nous obtenons alors
une cohrence intermodle permettant lalignement oprationnel.
Parmi les applications possibles de notre approche, nous abordons la notion de processus-
procd. Nous essayons de dterminer la corrlation existante entre processus et procd. Pour cela,
nous considrons successivement deux points de vue. Tout dabord un point de vue structurel, o nous
tablissons les liens existants entre les diffrents modles de processus et de procds utiliss dans
lingnierie des processus dentreprise et dans lingnierie des procds industriels. Nous constatons quil
est envisageable dinclure un diagramme de procds prliminaire au sein dun modle de processus.
Nanmoins, cette approche verticale doit tre ralise avec le support dontologies. Nous les abordons
en adoptant un point de vue smantique. A travers cette vue, nous cherchons dfinir les liens existants
entre ontologies de domaines, et rgles mtiers. Notre approche permettrait dassurer un alignement
entre diffrents modles multi-chelles de lentreprise. Il sera possible dappliquer notre mthode pivot de
manire pouvoir gnrer depuis un diagramme de processus dentreprise, un fichier de simulation
orient PSE.
13.3 SYNTHESE DES CONTRIBUTIONS
Les diffrentes contributions principales de nos travaux sur lapproche gnrique pour la
modlisation et limplmentation des processus sont rcapitules dans le Tableau 24.
Suite ces contributions, nous abordons les limites et perspectives de nos travaux. Les diffrents
points rencontrs peuvent se diviser en deux grandes catgories : les sujets directement lis nos
travaux, assurant une continuation et les sujets sintressant aux possibilits offertes lissue de ce
manuscrit mais dont les recherches dans le domaine associ restent prospectives.


Tableau 24. Synthse des contributions

Proprits Contributions apportes par lapproche et la plateforme SCALP
P1. Multi-Domaine
La plateforme intgre le cycle de vie complet du processus mtier,
depuis lenvironnement danalyse celui dimplmentation.

P2. Indpendance des environnements
Le modle danalyse ne prend pas en compte les informations
ncessaires la plateforme dimplmentation. Ici, le modle pivot sert
de modle intermdiaire.

P3. Prise en considration des modifications
Grce lutilisation de mtamodles et du mapping effectu entre
eux, la propagation des modifications se ralise aisment.

P4. Evolution des outils
Lutilisation dun pivot permet de faciliter les volutions des outils. La
modification dun environnement danalyse (resp. implmentation) na
aucun impact envers lenvironnement dimplmentation (resp.
analyse)

P5. Synchronisation
Le modle pivot permet de restituer les informations lors des
diffrentes transformations. La proprit P3 est galementvrifie,
notre plateforme permet donc dobtenir une synchronisation entre
modles.

P6. Equivalence smantique
Lutilisation de fonctions de conformit constructive (elles-mme
utilisant Ecore et Kermeta) permet dobtenir une quivalence
smantique entre modles.

P7. Cohrence intermodle
Les proprits P5 et P6 tant vrifies nous obtenons une cohrence
intermodle laide de la plateforme propose.

P8. Comportement
Le comportement (avec entre autre les rgles mtier) de chaque
lment dun mtamodle est reprsent au sein du fichier Visiteur
associ (intalioVisitor.kmt, pivotVisitor.kmt, openERPVisitor.kmt).

P9. Couplage faible P2 et P4 tant vrifies, la mise en uvre de cette approche permet
dobtenir un couplage faible entre environnements danalyse et
dimplmentation.

P10. Transformation Les transformations sont ralises laide de loutil de
mtamodlisation Kermeta.
13.4 LIMITES ET PERSPECTIVES
13.4.1 Utilisation et utilit de la plateforme SCALP
La mise en uvre de notre approche rsulte en une plateforme complexe, manipulant divers
technologies et outils. Or cette complexit en elle-mme dmontre lutilit dune telle approche. Elle
permet de concilier des environnements diffrents et autonomes, tout en manipulant leurs modles. Ces
modles sont htrognes et dabstractions diffrentes. Nous avons montr que plusieurs conditions
taient ncessaires afin dobtenir une cohrence intermodle. Nanmoins cette cohrence et ce travail
en amont ne sont pas justifiables pour des transformations unilatrales, depuis BPA vers BPI. Ainsi,
lutilisation de notre approche se justifie si et seulement si nous dsirons obtenir des transformations
bilatrales formellement dfinies. Tout au long du manuscrit, nous avons montr que cette transformation
bilatrale se situait au cur dune dmarche dalignement de linfrastructure mtier et des processus
dentreprise et les infrastructures SI.
172 EPILOGUE

Il faudrait cependant prouver notre plateforme en utilisant des processus plus spcifiques issus
par exemple de PME/PMI. De mme, pour tayer la proprit couplage faible de notre plateforme,
son utilisation avec de nouveaux outils est envisage (par exemple Bizagi Process Modeler en amont et
un outil bureautique type Microsoft Excel en aval).
13.4.2 Gnration de code et orchestration de services
De nombreux travaux proposent des dmarches orientes services vers les SI permettant une
transformation depuis BPA vers BPI, comme la mthode ADORE dveloppe par (Mosser 2010) et
utilise dans le projet FAROS. Lapproche que nous proposons fut dveloppe dans une optique de
gnration de code. Prendre en considration une optique dorchestration de services prexistants
pourrait complter notre approche. Pour cela, les mcanismes manipulant la partie pivot de notre
approche devront tre modifis et fournir des mthodes de dcomposition ou dtection des lments du
processus en services dclars pralablement. La plateforme cible serait des SI base de composants
ou packages standards de services.
13.4.3 Alignement stratgique, alignement oprationnel
27

A laide de notre approche, nous avons cherch dfinir les liens existants entre les SI
(infrastructures et processus techniques) et les units mtier (infrastructures et processus dentreprise),
et ainsi dapporter notre contribution la littrature. Nous avons ainsi rduit nos travaux au domaine
interne en nous proccupant essentiellement de ces infrastructures SITI et des processus dentreprise.
Des travaux futurs pourront tre mens sur la relation entre domaine interne et les stratgies employes
par lentreprise. Ltude de cet ajustement stratgique, mene notamment par (Thevenet 2009) et (Avila
2008) permettrait dlargir les possibilits de notre approche. Nous serions en mesure de conceptualiser
lensemble des squences dalignement telles que dfinies par le SAM.
La prochaine tape serait alors de permettre lingnierie dirige par les processus, Process-driven
engineering, tape supporte par notre approche et plateforme SCALP.
13.4.4 Abstraction et interoprabilit
Nous avons sciemment rduit le nombre de pools utilisable dans un BPD. Ainsi, nous manipulons
un unique pool, englobant lensemble des lments du BPD et sidentifiant ce dernier. De futurs travaux
permettrons dutiliser n-pools est ainsi dobtenir des processus interentreprises. Il convient alors de
sinterroger sur la place de notre plateforme et de lenvironnement pivot qui la dfinit.
De nombreux travaux se proccupent des processus collaboratifs, en particulier (Rajsiri 2009) pour
le niveau CIM et (Touzi 2007) pour les niveaux PIM-PSM. Nous pouvons galement citer les travaux de
(Fathallah 2010) qui, dans un cadre dinteroprabilit dentreprises, cherchent dfinir et maintenir la
cohrence entre les diffrents SI dentreprises selon les typologies de modles utilises.

27
Au regard de la section 2.2.1, le lecteur averti pourra apprcier lpanadiplose !

13.4.5 Evolution de la plateforme SCALP
Le mtamodle pivot se restreint pour le moment un ensemble de 18 objets. Ceci nous a permis
de d-complexifier notre champ dtude. Afin de rendre ce mtamodle plus complet et donc le modle
pivot plus expressif, des dveloppements sont en cours afin dobtenir lensemble dlments constituant
la classe standard de conformit de portabilit de modle tel que dfini par la WfMC. Des travaux futurs
sont envisageables quant la possibilit dobtenir la classe de conformit complte.
Une autre volution possible prendre en compte est la possibilit dinclure un environnement
ddi la supervision des processus mtier, le BAM. Son rle serait de fournir les outils ncessaires
permettant dobtenir un retour dinformations sur lutilisation et lexcution des processus issu de
lenvironnement SITI. Les informations devront ensuite tre transmises lenvironnement mtier sous
forme de KPIs significatifs.
La mthode prsente dans ce manuscrit se veut gnrique. Afin dtre le plus libre possible,
nos choix technologiques se sont orients vers le domaine du logiciel libre ( open-source ). Il convient
ds lors de sinterroger sur la prennit des outils utiliss pour constituer notre plateforme, notamment
avec le langage de mtamodlisation Kermeta. Il sagira de constater si ce langage est maintenu et suit
les volutions de lEclipse Modeling Framework.
13.4.6 Extension de lapproche SCALP au domaine Process Systems Engineering
La piste emprunte par notre dmarche et dcrite chapitre 12 a pour vocation dtre dveloppe
plus en dtail. Les travaux mens par (Heinz et al. 2011) vont dans ce sens. Ces travaux sinscrivent
dans le projet InBioSynSolv
28
: Un laboratoire virtuel pour une chimie durable . Le but est de
dvelopper un prototype logiciel de type Computer Aided Molecular Design - CAMD utilisant la formulation
inverse afin de rechercher des produits chimiques satisfaisant un cahier des charges prdfini. Dans le
but dtre au plus proche des problmes traiter, les solutions recherches sont des mlanges de
molcules. Le cahier des charges intgre la fois des proprits fonctionnelles et des proprits valuant
limpact environnemental et sanitaire... Le dveloppement logiciel associ ce projet sinspire des
concepts de notre approche assurant lalignement des diffrents modles du systme. Cette conception
repose sur diffrents modles danalyse (UML, BPMN) et sur les modles dimplmentation orients objet
ddis au framework .NET de Microsoft (C#, VB.NET). Ces travaux porteront galement sur la
dtermination et la formalisation des relations smantiques entre lingnierie des processus et lingnierie
des procds.
Ces diffrentes perspectives sont en accord avec notre volont dapporter au Laboratoire de Gnie
Chimique et en particulier au dpartement Procds et Systmes Industriels nos connaissances
relatives au domaine de lIngnierie dEntreprise et des Systmes dInformation et de lingnierie des
processus mtier. Le but recherch est dtre en mesure dappliquer nos ides lingnierie des
procds, en particulier dans un contexte de dveloppement durable et de chimie verte ( Green
Chemistry et Green Process Engineering ).

28
Programme ANR 2008 : ANR-09-CP2D-08, Chimie et Procds pour le Dveloppement Durable
174 EPILOGUE

14. Bibliographie

C
H
A
P
I
T
R
E

14
176 EPILOGUE

A
Aloui, S. 2007. Contribution la modlisation et l'analyse du risque dans une organisation de sant au moyen d'une
approche systme. Thse de doctorat, Ecole des Mines de Paris.
Alter, S. 1999. "A general, yet Useful Theory of Information Systems", in Association for Information Systems, vol.1.
American Chemical Society, American Institute of Chemical Engineers, Chemical Manufacturers Association, Council
for Chemical Research, & Synthetic Organic Chemical Manufacturers Association 1996. Technology Vision 2020.
AMICE 1993. CIMOSA: Open System Architecture for CIM, Second extended and revised version ed. Springer-Verlag,
Berlin.
Amit, R. & Schoemaker, P. J. H. 1993, "Strategic Assets and Organizational Rent," In Strategic Management Journal,
vol. 14 pp. 33-46.
Anaya, V., Berio, G., Harzallah, M., Heymans, P., Matulevicius, R., Opdahl, A. L., Panetto, H., & Verdecho, M. J. 2008,
The Unified Enterprise Modelling Language Overview and Further Work, IFAC Papersonline.
Avila Cifuentes, O.J. 2009. Contribution l'Alignement Complet des Systmes d'Information Techniques. Laboratoire de
Gnie de la Conception (LGeCo) - Thse de doctorat, Universit de Strasbourg.
Avison, D., Jones, J., Powell, P., & Wilson, D. 2004, "Using and validating the strategic alignment model," In Journal of
Strategic Information Systems, vol. 13 pp. 223-246.
B
Bana, S. 2006. Interoprabilit Dirige par les Modles: Une Approche Oriente Produit pour l'Interoprabilit des
Systmes d'Entreprise. Thse de doctorat, Facult des Sciences et Techniques.
Baptiste, J.-L. 2009. Merise - Guide Pratique - Modlisation des donnes et des traitements, langage SQL, Eyrolles.
Bayer, B., Weidenhaupt, K., Jarke, M., & Marquardt, W. 2001, "A Flowsheet-centered architecture for conceptual
design," In European Symposium on Computer Aided Process Engineering, vol. 9 pp. 345-350.
Bayer, B. & Marquardt, W. 2003, "A Comparison of Data Models in Chemical Engineering," In Concurrent Engineering,
SAGE Publications, ed., pp. 129-138.
Belaud, J.-P. 2002. Architectures et technologies des systmes logiciels ouverts - Cape-Open, un standard pour
l'introprabilit et l'intgration des composants logiciels de l'ingnierie des procds. Thse de doctorat, Institut
National Polytechnique (INP) de Toulouse.
Bzivin, J. & Blanc, X. MDA: Vers un Important Changement de Paradigme en Gnie Logiciel. Dveloppeur Rfrence .
2002.
Bzivin, J. 2004, "Sur les principes de base de l'ingnierie des modles," In L'Objet, vol. 10 pp. 147-157.
Bidan, M. 2004, "Fdration et intgration des applications du Systme d'Information de Gestion," In Revue Systmes
d'Information et Management (SIM) - n spcial Risques des projets ERP, vol. 9.
Blay-Fornarino, M., Dao, M., Lahire, P., & Rivierre, N. 2008, Transformations depuis les modles mtier, Livrable F-2.4.
Bloch, A. & Krob, D. 2005, L'Entrepreneur Face au Systme d'Information: un Enjeu de Formation ?, Les Echos.
Boucher, X. 2007. Vers un pilotage agile de l'volution des systmes de production. Habilit Dirige les Recherches,
Ecole Nationale Suprieure des Mines de Saint-Etienne.
14. BIBLIOGRAPHIE 177

Bouchiba, A. & Cherkaoui, A. 2007, Contribution de la modlisation combine avec l'approche baysienne dans
l'amlioration des performances des processus mtiers - Cas de la sret ferroviaire au niveau de l'ONCF., CPI'2OO7.
BPMS.Info. BPMN 2.0: ce que la nouvelle version de la notation va apporter (ou pas). Le Journal du Net,
www.journaldunet.com - Tribunes BPMS.Info . 25-6-2009.
Broadbent, M. & Weill, P. 1993, "Improving business and information strategy alignment: Learning from the banking
industry," In IBM Systems Journal, vol. 32 pp. 162-179.
C
Chan, Y. E., Huff, S. L., & Barclay, D. W. 1997, "Business Strategic Orientation, Information Systems Strategic
Orientation and Strategic Alignment," In Information Systems Research, vol. 8 pp. 125-150.
Combemale, B. Ingnierie Dirige par les Modles (IDM) -- tat de l'art. http: and hal.archives-ouvertes.fr/hal-
00371565/en/. 2009.
Cuenca, L., Ortiz, A., & Boza, A. 2010, "Business and IS/IT Strategic Alignment Framework," In Emerging Trends in
Technological Innovation, vol. 314/2010 IFIP Advances in Information and Communication Technology, pp. 24-31.
D
Darras, F. 2004. Proposition d'un Cadre de Rfrence pour la Conception et l'Exploitation d'un Progiciel de Gestion
Intgr. Thse de doctorat, cole des Mines d'Albi-Carmaux.
Dassiti, M. 2006, Research directions in enterprise modelling for interoperability and integration DEM 3 - IST-508 011.
David, R. & Alla, H. 1992. Du GRAFCET aux Rseaux de Ptri Paris, Herms.
Debauche, B. & Megard, P. 2004. BPM Business Process Management : pilotage mtier de l'entreprise Lavoisier.
E
Earl, M. J. 1992, "Putting IT in its place: a polemic for the nineties," In Journal of Information Technology, vol. 7 pp.
100-108.
Edgar, T. F. 2004, "Control and operations: When does controllability equal profitability?," In Computer & Chemical
Engineering, vol. 29 Elsevier, ed., pp. 41-49.
Etien, A. 2006. Ingnierie de l'alignement: Concepts, Modles et Processus - La mthode ACEM pour l'alignement d'un
systme d'information aux processus d'entreprise. Thse de doctorat, Universit Paris I - Panthon - Sorbonne.
F
Fathallah, A., Stal-Le Cardinal, J., Ermine, J.L., & Bocquet, J.C. 2010, "Enterprise modelling: building a product lifecycle
management model as a component of the integrated vision of the enterprise", in International journal on Interactive
Design and Manufacturing (IJIDeM), vol. 4, n3, pp.201-209.
Faucher, C., Bertrand, F., & Lafaye, J.-Y. 2008, "Gnration d'ontologie partir d'un modle mtier UML annot," In
Revue des Technologies de l'Information - RNTI 12: Modlisation des connaissances, Cpadus-dition, ed., pp. 65-84.
Favre, J.-M., Estublier, J., & Blay-Fornarino , M. 2006. L'ingnierie dirige par les modles : au-del du MDA Paris,
Herms Science Publications.
Ferchichi, A. 2008. Contribution l'intgration des processus mtier: Application la mise en place d'un rfrentiel
qualit multi-vues. Thse de doctorat, Ecole Centrale de Lille - Ecole Centrale de Paris.
178 EPILOGUE

Fingar, P. & Bellini, J. 2004. The Real-Time Enterprise New York, Meghan-Kiffer Press.
Fontan, B. 2008. Mthodologie de conception de systmes temps rel et distribus en contexte UML/SysML. Thse de
doctorat, Universit Paul SAbatier - Toulouse III.
G
Gamma, E., Helm, R., Johnson, R., & Vlissides, J. 1999. Design Patterns - Catalogue de modles de conception
rutilisables Vuibert.
Garcs, R., Cardoso, J., & Valente, P. 2009, "Open Source Workflow Management Systems: A Consive Survey," In 2009
BPM & Workflow Handbook - Spotlight on BPM in Government, L. Fischer, ed., WfMC, pp. 333-346.
Godart, C. & Perrin, O. 2009. Les processus mtiers - Concepts, modles et systmes, 1re dition ed. Herms -
Lavoisier.
Gordon, J. R. & Gordon, S. R. 2000, "Structuring the interaction between IT and business units: Prototypes for service
delivery," In Information System Management, vol. 17 pp. 7-16.
Grangel, R., Ben Salem, R., Bourey, J.-P., Daclin, N., & Ducq, Y. 2007, "Transforming GRAI Extended Actigrams into UML
Activity Diagrams: a First Step to Model Driven Interoperability," In Enterprise Interoperability II - New Challenges and
Approaches, Springer London, ed., pp. 447-458.
Grossmann, I. E. 2004, "Challenges in the new millennium: product discovery and design, enterprise and supply chain
optimization, global life cycle assessment," In Computers & Chemical Engineering, vol. 29 Elsevier, ed., pp. 29-39.
Gruber, T. 1993. A Translation Approch to Portable Ontology Specifications, Vol.5 ed. Knowledge Acquisition.
Guarino, N. 1998. "Formal Ontology in Information Systems", in Proceedings of FOIS'98, Trento, Italie, pp. 3-15.
H
Havey, M.V. & Havey, M. 2005. Essential Business Process Modeling, O'Reilly Media, Incorporated.
Hay, D. & Healy, K. A. 1997, GUIDE - Business Rule Project Final Report.
Heinz, J., Gerbaud, V., & Belaud, J.-P. 2011, "Models driven conception of an inverse formulation software tool," en
cours de soumission In 21st European Symposium on Computer Aided Process Engineering - ESCAPE 21, Elsevier.
Henderson, J. C. & Venkatraman, N. 1993, "Strategic alignment: Leveraging information technology for transforming
organizations," In IBM Systems Journal, vol. 32 pp. 3-16.
Henderson, J. C. & Venkatraman, N. 1999, "Strategic Alignment: Leveraging information technology for transforming
organizations," In IBM Systems Journal, vol. 38 n2 IBM, ed., IBM, pp. 472-484.
Hettel, T. 2010. Model Round-Trip Engineering. Faculty of Science and Technology.
Hirao, M., Sugiyama, H., Fischer, U., & Hungerblher, K. 2008, "IDEF0 Activity Modeling for Integrated Process Design
Considering Environmental, Health and Safety (EHS) Aspects," In 18th European Symposium on Computer Aided
Process Engineering - ESCAPE18, B. Braunschweig & X. Joulia, eds., Elsevier, pp. 1065-1070.
Hollingsworth, D. 2004, "The Workflow Reference Model : 10 Years On,".Workflow Management Coalition.
I
IEEE 2000, Recommended Practice for Architectural Description of Software Intensive IEEE-std-1471-2000.

IFAC-IFIP Task Force 1997, GERAM: Generalized Enterprise Reference Architecture and Methodology (patent).
ISO TC 184/SC 5 2000, ISO 15704:2000 - Industrial Automation Systems - Requirements for enterprise-reference
architectures and methodologies (patent).
Izza, S. 2006. Intgration des Systmes d'Information Industriels - Une Approche Flexible Base sur les Services
Smantiques. cole Nationale Suprieure des Mines de Saint-Etienne.
J
Jablonski, S. 2009, "Process Modeling for Holistic Process Management," In Handbook of Research on Business Process
Modeling, J. Cardoso & W. M. van der Aalst, eds., Information Science, pp. 49-68.
K
Kadima, H. 2005. MDA : conception oriente objet guide par les modles, Dunod, Paris.
Klatt, K.-U. & Marquardt, W. 2009, "Perspectives for process systems engineering - Personal views from academia and
industry," In Computers & Chemical Engineering, vol. 33 Elsevier, ed., pp. 536-550.
Klein, J. & Fleurey, F. Tissage d'aspects comportementaux, In Langages et Modles Objets - LMO'06, Herms
Lavoisier, pp. 101-116.
L
LAAS-CNRS 2003, Rapport final de l'Action Spcifique n35 - AS PRODLOG "Production et logistique dans l'entreprise
tendue: modles et outils collaboratifs" INSA Toulouse.
Laleau, R. 2002. Conception et Dveloppement Formels d'Applications Bases de Donnes. Universit d'Evry Val-
d'Essonne.
Le Moigne, J.-L. 1984. La Thorie du Systme Gnral, Edition Presse Universitaire Franaise.
Leist, S. & Zellner, G. Evaluation of Architecture Frameworks, In Organizational engineering (OE), ACM, pp. 1546-1553.
Lemoigne, J.-L. 1984. La thorie du systme gnral, Edition Presse Universitaire Franaise.
Lequeux, J.-L.W. 2008. Manager avec les ERP -- Architecture Oriente Services (SOA), 3me dition ed. Editions
d'organisation.
List, B. & Korherr, B. An evaluation of conceptual business process modelling languages, In Symposium on Applied
computing'06, New York, NY, USA: ACM, pp. 1532-1539.
Luftman, J. & Brier, T. 1999, "Achieving and Sustaining Business-IT Alignment," In California Management Review, vol.
42 pp. 109-122.
Luftman, J. & Maclean, E. R. 2004, "Key issues for IT executives," In MIS Quaterly Executive, vol. 4, n2 University of
Minnesota, ed., University of Minnesota.
M
Malone, T.W., Crowston, K., & Herman, G.A. 2003. Organizing Business Knowledge - The MIT Process Handbook, MIT
Press.
Marquardt, W., Morbach, J., & Yang, A. 2010. OntoCape - A Re-Usable Ontology for Chemical Proces Engineering.
180 EPILOGUE

Marquardt, W., von Wedel, L., & Bayer 1999, Perspectives on lifecycle process modeling, In FOCAPD '99: 5th
international conference on foundations of computer-aided process design.
Martin, R. A., Robertson, E. L., & Springer, J. A. 2004, Architectural Principles for Enterprise Frameworks, Computer
Science Department, Indiana University, Bloomington, Indiana.
Mendling, J., Newman, J., & Nttgens, M. 2004. "A Comparaison of XML Interchange Formats for Business Process
Modelling", In EMISA 2004.
Morley, C., Hugues, J., Leblanc, B., & Hugues, O. 2007. Processus mtiers et S.I. Evaluation, modlisation, mise en
uvre, DUNOD.
Mosser, S. 2010. Behavioral Compositions in Service-Oriented Architecture. Thse de doctorat, Universit de Nice-
Sophia Antipolis.
Mosser, S. & Blay-Fornarino, M. Rflexions autour de la construction dirige par les modles d'un atelier de
composition d'orchestrations, In Langages et Modles Objets - LMO'09.
Muller, P.-A., Fleurey, F., & Jzquel, J.-M. 2005, Weaving Executability into Object-Oriented Meta-Languages, In The
8th International Conference on Model Driven Engineering Languages and Systems (MODELS/UML'2005).
N
National Institute of Standards and Technology (NIST) 1993, Integration Definition for Funtion Modeling - IDEF0, 183
(patent).
O
OASIS 2007, WSBPEL - Web Service Business Process Execution Language (patent).
OMG 2003, BPDM - Business Process Definition Metamodel - Request for Proposal (patent).
OMG 2006, Meta Object Facility (MOF) Core Specification - Version 2.0 (patent).
OMG 2007a, UML 2.1.2 Superstructure specification (patent).
OMG 2007b, XML Metadata Interchange (XMI) - 2.1.1 - ISO/IEC 19503 (patent).
OMG 2008, BPMN - Business Process Modeling Notation Specification - OMG Final Adopted Specification (patent).
Ouyang, C., Van der Aalst, W. M. P., Dumas, M., & Ter Hofstede, A. H. M. 2006, Translating BPMN to BPEL.
P
Palmer, N. Understanding the BPMN-XPDL-BPEL Value Chain. Business Integration Journal . 2006.
Panetto, H. 2006. Mta-modles et Modles pour l'Intgration et l'Interoprabilit des Applications d'Entreprises de
Production. Habilit Dirige les Recherches, Universit Henri Poincar - Nancy 1.
Panetto, H. 2007. Towards a classification framework for interoperability of enterprise applications. International
Journal of Computer Integrated Manufacturing, 20, (8) 727-740 available from:
http://portal.acm.org/citation.cfm?id=1392537#
Panetto, H., Berio, G., Benali, K., Boudjlida, N., & Petit, M. A Unified Enterprise Modelling Language for enhanced
interoperability of Enterprise Models, In IFAC INCOM2004.

Peppard, J. & Ward, J. 2004, "Beyond Strategic Information Systems: Toward an IS Capability," In Journal of Strategic
Information Systems, vol. 13 pp. 167-194.
Perez, J. M., Ruiz, F., & Piattini, M. 2006, MDE for BPM: A systematic Review, In First International Conference of
Software and Data Technologies, ICSOFT 2006, J. Filipe, B. Shiskov, & M. Helfert, eds., Springer.
Pourcel, C. & Gourc, D. 2005. Modlisation d'entreprise par les processus: activits, organisation et applications
Toulouse, Cpadus-dition.
Pyke, J. 2006, "BPM in Context: Now and in the Future," In Workflow Handbook, L. Fisher, ed., Workflow Management
Coalition, pp. 17-28.
R
Rajsiri, V. 2009. Knowledge-based system for collaborative process specification. Thse de doctorat, Ecole des Mines
d'Albi-Carmaux.
Reix, R. 2004. Systmes d'Information et Management des Organisations Edition VUIBERT.
Roboam, M. 1993. La Mthode GRAI, Principes, Outils, Dmarche et Pratique Toulouse, Tekna.
Roques, P. & Valle, F. 2004. UML2 en action: De l'analyse des besoins la conception J2EE Eyrolles.
Roser, S. & Bauer, B. A categorization of collaborative business process modeling techniques, In Seventh IEEE
International Conference 2005, pp. 43-51.
Ross, R.G. 2003. Principles of the Business Rule Approach Boston, Addison-Wesley.
S
Sadiq, R., Kleiner, Y., & Rajani, B. 2004, "Aggregative risk analysis for water quality failure in distribution network," In
Journal of Water Supply: Research and Technology - AQUA, vol. 53(4) pp. 241-261.
Scheer, A.-W. 2002. ARIS : des processus de gestion au systme d'intgr d'applications Springler-Verlag France.
Schneider, R. & Marquardt, W. 2002, "Information technology support in the chemical process design life cycle," In
Chemical Engineering Science, vol. 57 pp. 1763-1792.
Silver, B. 2008, BPMS Watch Ratings for Q2 2008, BPMS Watch.
Silver, B. 2009. BPMN, Method and Style Cody-Cassidy press.
Silvius, D. A. J. G. Business & IT Alignment in theory and practice, In HICSS'07.
Smith, H. 2003. BPM and MDA: Competitors, Alternatives or Complementary Business Process Trends.
Smith, H., Neal, D., Ferrara, L., & Hayden, F. 2002. The Emergence of Business Process Management CSC's Research
Services.
SPINOV 2006, Modlisation des Processus Mtiers: Etat de l'Art et Conseils Pratiques, Rapport CITI.
Steel, J. & Jzquel, J.-M. 2004, "Typing Relationship in MDA," In Technical Report - University of Kent at Canterbury
Computing Laboratory, University of Kent, pp. 154-159.
Stein, S., Khne, S., & Ivanov, K. 2008, Business to IT Transformations Revisited, In BPM 2008.
Steinberg, D., Budinsky, F., Paternostro, M., & Merks, E. 2009. EMF, Eclipse Modeling Framework, 2nd ed. Boston.
182 EPILOGUE

Stevens, P. 2008, "A Landscape of Bidirectional Model Transformations," In Generative and Transformational
Techniques in Software Engineering II, vol. Volume 5235/2008 Springer Berlin / Heidelberg, ed., pp. 408-424.
T
Takamatsu, T. 1983, "The nature and role of process system engineering," In Computers & Chemical Engineering, vol. 7
pp. 203-218.
Tardieu, H., Rochfeld, A., & Rolland, C. 2002. La Mthode MERISE: Principes et Outils Editions de l'Organisation.
The Business Rules Group (BRG) 2007, The Business Motivation Model - Business Governance in a Volatile World,
Release 1.3.
Throude, F., Braesch C., Haurat A. 2001, "OLYMPIOS: un modle pour le pilotage des processus", in MOSIM'01 :
confrence francophone de modlisation et simulation, Troyes, France, 249-253.
Thevenet, L.-H. 2010. Proposition d'une modlisation conceptuelle d'alignement stratgique : La mthode INSTAL.
Thse de doctorat, Universit Panthon-Sorbonne.
Touzi, J. 2007. Aide la Conception de Systme d'Information Collaboratif Support de l'Introprabilit des Entreprises.
Thse de doctorat, Ecole des Mines d'Albi Carmaux.
Touzi, J., Bnaben, F., & Pingaud, H. 2008, "Prototype to Support Morphism between BPMN Collaborative Process
Model and Collaborative SOA Architecture Model," In Enterprise Interoperability III New Challenges and Industrial
Approaches, Springer London, pp. 145-157.
Truong Meyer, X.-M. 2009, "Modlisation en gnie des procds," In Techniques de l'ingnieur - Gnie des procds,
vol. JB1, nJ1021 [Note(s): J1021.1-J1021.18].
U
Ulmer, J.-S., Belaud, J.-P., & Le Lann, J.-M. 2008, Analyse de l'expressivit des langages de modlisation de processus
par les patterns, In Inforsid'08, Fontainebleau, France.
Ulmer, J.-S., Belaud, J.-P., & Le Lann, J.-M. 2009, Proposition d'une mthodologie gnrique pour la formalisation et
l'implmentation des processus, In XXVIIme congrs INFORSID, Toulouse, France, pp. 43-58.
Ulmer, J.-S., Belaud, J.-P., & Le Lann, J.-M. 2010a, "Proposition d'une approche gnrique pour la formalisation et
l'implmentation des processus," In Networking and Information Systems - Revue des sciences et technologies de
l'information, vol. 15, n4/2010.
Ulmer, J.-S., Belaud, J.-P., & Le Lann, J.-M. 2010b, Towards a pivotal-based approach for Business process alignment, In
8
th
International Conference of Modeling and Simulation - MOSIM'10 -"Evaluation and optimization of innovative
production systems of goods and services".
Uschold, M. & Gruninger, M. 1996. Ontologies: Principles, Methods and Applications. Knowledge Engineering Review,
Cambridge University Press, vol.11-02, pp.93-136
V
Van der Aalst, W. M. P. 2004, "Business Process Management Demystified: A Tutorial on Models, systems and
Standards for Workflow Management," In Lectures in Concurrency and Petri Nets, Springer Berlin Heidelberg, ed., pp.
21-58.
Various IIBA & Brennan, K. 2008. A Guide to the Business Analysis Body of Knowledge (BABOK), v.1.6. ed. Canada,
International Institute of Business Analysis.

Varma, V. A., Reklaitis, G. V., Blau, G. E., & Pekny, J. F. 2007, "Enterprise-wide modeling & optimizationAn overview
of emerging research challenges and opportunities," In Computers & Chemical Engineering, vol. 31 pp. 692-711.
Vernadat, F.B. 1999. Techniques de Modlisation en Entreprise: Applications aux Processus Oprationnels Paris,
Economica.
Vernadat, F. & Hamaidi, L. 1998. La modlisation en entreprise: Mthodes descriptives des processus oprationnels
Paris, Economica.
Vernadat, F. B. 2007, "Interoperable enterprise systems: Principles, concepts, and methods," In Annual Reviews in
Control, vol. 31 Elsevier, ed., pp. 137-145.
von Halle, B. 2002. Business Rules Applied, John Wiley & Sons, New York.
W
Wagner, H.-T., Beimborn, D., Franke, J., & Weitzel, T. IT Business Alignment and IT Usage in Operational Processes: A
Retail Banking Case, In 39th Hawaii International Conference on Systems Science, IEEE Computer Society.
Ward, J. & Peppard, J. 2002. Strategic Planning for Information Systems John Wiley & Sons, Ltd, 3rd Edition.
Weidlich, M., Decker, G., Grokopf, A., & Weske, M. BPEL to BPMN: The Myth of a Straight-Forward Mapping, In OTM
2008, Berlin: Springer-Verlag, pp. 265-282.
WfMC 1999, Workflow Management Coalition - Terminoly and Glossary - WFMC-TC-1011 (patent).
Y
Yang, A., Braunschweig, B., Fraga, E. S., Guessoum, Z., Marquardt, W., Nadjemi, O., Paen, D., Piol, D., Roux, P., Sama,
S., Serra, M., & Stalker, I. 2008, "A multi-agent system to facilitate component-based process modeling and design," In
Computers & Chemical Engineering, vol. 32 Elsevier, ed., pp. 2290-2305.
Z
Zur Muehlen, M. 2004. Workflow-based Process ControllingFoundation, Design, and Application of Workflow-driven
Process Information Systems Berlin, Logos Verlag.
Zur Muehlen, M. Business Process Management Standards - An Overview. 2008.
Zur Muehlen, M. & Recker, J. 2008, How Much Language is Enough? Theorical and Practical Use of the Business
Process Modeling Notation, In 20th International Conference on Advanced Information Systems Engineering (CAISE
2008), Springer, ed..

15. Annexes

C
H
A
P
I
T
R
E

15
186 EPILOGUE

15.1 GLOSSAIRE

A
Agilit Dfinit la capacit dune entreprise sadapter rapidement son
environnement, procder des changements harmonieux et continus
de lorganisation.
.. 27
Ajustement stratgique Voir Domaines externes, domaines internes .. 25
Alignement oprationnel Maintenir un alignement oprationnel revient conserver une cohrence
smantique et structurelle entre modles htrognes et
dabstraction/granularit diffrentes. Elle est souvent perue comme
lintgration fonctionnelle.
.. 27
Alignement stratgique Amlioration de la performance organisationnelle travers divers
mcanismes comme les processus de pilotage, les ressources humaines et
les capacits technologiques, o ces capacits peuvent tre interprtes
essentiellement comme la capacit dployer des ressources.
.. 25
Analyse des processus
mtier
Ou Business Process Analysis BPA. Etapes de conception et de
modlisation des processus ralises par lanalyste mtier.
.. 62
Analyste mtier Acteur recherchant de nouvelles faons damliorer lefficacit mtier
de son entreprise. Cette amlioration peut tre ralise en modifiant la
manire de travailler collectivement, en changeant doutils ou de
processus
.. 49
Architecte des processus
mtier
Concilie les deux niveaux dabstractions propres lanalyste mtier et
lexpert SITI, lacteur pivot permet de fluidifier les changes et
dobtenir une meilleure cohrence entre diffrents modles (danalyse et
technique). Il possde les connaissances fonctionnelles et technologiques
ncessaires pour dfinir un style architectural BPM appliquer au sein
de lorganisation.
.. 92
Architecture Dirige par
les Modles
Ou Model-DrivenArchitecture - MDA. Approche mettant en avant lutilisation
systmatique de modles comme support la conception et au
dveloppement de diffrents types de systmes. MDA utilise trois types
de modles situs niveaux d'abstraction diffrents : CIM, PIM et PSM.
.. 55
C
Cadre de modlisation Approche, incluant un ensemble de composants - modles et dfinitions -
formant un squelette adaptable et/ou modifiable au domaine
dapplication de lentreprise et ce dans le but de dvelopper et
documenter les descriptions darchitecture.
.. 40
Chorgraphie Permet de composer une collaboration entre plusieurs entits
autonomes. Le comportement global merge en fonction de linteraction
et du rsultat de chaque processus (entits).
.. 114
Cohrence intermodle Il existe une cohrence dite intermodle entre deux modles si nous
observons une quivalence smantique et sils sont synchroniss entre
eux.
.. 80
Computation Independent
Model - CIM
Modles abstraits associs aux exigences dun systme et/ou un
domaine mtier. Le CIM dcrit usuellement lenvironnement, les
processus mtier et objets ainsi que les exigences spcifiques du systme.
Il permet de dfinir les rgles et le vocabulaire mtier et reprsente
laspect organisationnel du systme.
.. 55
15. ANNEXES 187

Couplage faible Dfinit une interaction forte o les modles demeurent autonomes et
les environnements associs restent modifiables.
.. 72
Cycle de vie Reprsentation des diffrents niveaux de drivation dun modle. Il dcrit
le modle depuis lnonc des prescriptions pour arriver un modle
traitable par informatique .
.. 40
D
Dmarche en Y Ou 2 Tracks Unified Process. Processus de dveloppement logiciel pour la
description de larchitecture logicielle en dissociant les aspects
fonctionnels (approche par les fonctionnalits) des aspects technique
(tude de la mise en uvre).
.. 55
Domaines externes
Domaines internes
Le domaine externe porte sur la formulation des stratgies refltant
l'environnement dans lequel sinscrit lentreprise. Le domaine interne se
proccupe de linfrastructure SITI et des processus dentreprise.
Lajustement stratgique dcrit la relation verticale existant entre un
domaine externe et le domaine interne qui lui est associ. Lintgration
fonctionnelle reprsente la relation horizontale existant entre deux
domaines.
.. 25
E
Entreprise Systme sociotechnique ouvert et dynamique motiv par un ou plusieurs
buts et objectifs.
.. 35
Equivalence smantique Les modles i et j sont smantiquement quivalents si : Pour chaque
lment appartenant E
i
, un lment (ou un ensemble dlments)
appartenant E
j
peut lui tre associ ; Chacun de ces lments associs
suit la mme orchestration.
.. 79
Expert SITI Acteur prenant en charge les besoins mtier dfinis par lanalyste mtier
et les transforme selon des considrations techniques.
.. 49
F
Flexibilit Est semblable la notion de ractivit industrielle. Elle traduit la capacit
dune entreprise rpondre rapidement aux besoins de ses clients par
une utilisation diffrente de ses ressources.
.. 27
G
Gnricit relative Gnricit limite un domaine mtier (services bancaires, procds
physico-chimiques), un contexte dtude et au niveau dabstraction
recherch.
.. 92
I
Implmentation des
processus mtier
Ou Business Process Implementation BPI. Etapes dimplmentation et
dexcution des processus ralises par lexpert SITI.
.. 64
Indicateur cl de
performance
Ou Key Performance Indicator KPI. Mtriques calculs sur la base des
mesures obtenues depuis le BPI, ils permettent de mesurer la
performance et latteinte des buts organisationnels fixs.
.. 66
Ingnierie des processus
mtier
Ou Business Process Management BPM. Permet de modliser, dployer,
excuter et optimiser de manire continue les diffrents types de
processus et ainsi damliorer lagilit dune organisation laide des
technologies de linformation
.. 49
188 EPILOGUE

Ingnierie Dirige par les
Modles - IDM
Ou Model-DrivenEngineering, MDE. Approche intgrative gnrale mettant
disposition des outils, concepts et langages pour crer et transformer des
modles.
.. 53
Intgration fonctionnelle Voir Domaines externes, domaines internes .. 25
M
Meta-Object Facility - MOF Socle sur lequel les langages de modlisation se basent travers la couche
dabstraction : mta-mtamodle.
.. 57
Mthode de Modlisation
dEntreprise - MME
Dcrit les aspects comportementaux (notamment la gestion des
vnements), fonctionnels et dynamiques, ainsi que la formalisation des
savoir-faire dune entreprise.
.. 38
Mtier Ensemble dactivits dun domaine donn ncessitant des comptences et
savoir-faire des acteurs de lentreprise.
.. 34
Modle danalyse Modle conceptuel reprsentant le processus mtier selon un point de
vue monde rel , sexprimant laide de termes mtier exprims
gnralement dans un langage naturel.
.. 81
Modle dimplmentation Modle technique adoptant un point de vue informatique et utilisant
des notions et de termes propres aux SITI.
.. 66
Modlisation dentreprise A pour objet la construction du modle de tout ou partie de lentreprise.
Lentreprise est alors vue comme un systme et sa modlisation doit en
expliquer la structure, lorganisation et le fonctionnement.
.. 38
O
Orchestration Dfinit lensemble des tapes internes un processus incluant conditions
et exceptions.
.. 34
P
PlateformIndependent
Models - PIM
Dcrivent tout ou partie des fonctionnalits du systme modlis sans se
soucier des dtails techniques. Modle conceptuel indpendant de toutes
considrations lies la plateforme cible, son langage ou la
technologie usite.
.. 55
PlatformSpecific Models -
PSM
Modle associ une plateforme spcifique base sur une technologie
bien dfinie.
.. 55
Processus dentreprise Ensemble dactivits, entreprises dans un objectif dtermin. .. 23
Processus de mesure Fournissent les mtriques ncessaires lvaluation des processus et
leur amlioration continue.
.. 41
Processus de pilotage Ou processus de management. Ils ont pour but dorganiser les objectifs
stratgiques de lentreprise.
.. 25
Processus de support Ou processus de soutien. Priphriques au mtier de lentreprise, ils ne
participent quindirectement laccomplissement dun objectif mtier.
.. 44
Processus mtier Orchestration dactivits, incluant une interaction entre diffrents acteurs
sous la forme dchange dinformations, ralisant des objectifs mtier.
.. 34
Processus oprationnel a pour fonction daccomplir une mission dans un domaine donn et utilise
plusieurs fonctions de lentreprise.
.. 44
15. ANNEXES 189

Progiciel de Gestion
Intgr PGI
Ou Enterprise Resource Planning ERP. Solution logiciel grant l'ensemble
des processus oprationnels par lintgration de l'ensemble des fonctions
du processus considr.
.. 44
R
Rgle mtier Formulation qui permet de structurer, de contrler ou dinfluencer le
comportement du mtier.
.. 83
S
Suite BPM Ou BPM Suite BPMS. Plateforme intgre dun diteur unique
rassemblant tous les composants ncessaires au dveloppement et
lexcution dune solution BPM : modlisation et analyse, orchestration
automatise, tches humaines, intgration des applications, rgles
mtier, et supervision.
.. 68
Supervision des processus
mtier
Ou Business Activity Monitoring BAM. Fournit un accs en temps rel un
ensemble dindicateurs danalyse de performance, Key Performance
Indicators (KPI) et procure un contrle et une amlioration constants des
processus mtier.
.. 66
Synchronisation Deux modles, i et j, sont dits synchroniss si et seulement si des
changements significatifs effectus sur le modle i peuvent tre
rpercuts sur le modle j. Est considr comme significatif tout
changement modifiant la structure et/ou le comportement dun modle.
.. 28
Systme dInformation
SI
Reprsente la partie relle constitue dinformations organises et
dacteurs qui agissent sur ces informations ou partir de ces
informations, selon des processus visant une finalit de gestion et utilisant
des technologies de linformation.
.. 35
Systme de Gestion des
rgles mtier
Ou Business Rules Management Suite BRMS. Fournit une suite de
fonctionnalits typiques pour la gestion des rgles mtier.
.. 83
Systme workflow Dfinit, cre et gre lexcution de workflows laide dun logiciel capable
dinterprter la dfinition du processus, interagir avec les participants du
workflow et est capable dutiliser des outils SITI.
.. 62
V
Vue Reprsentation de tout un systme selon la perspective dun ensemble
dintrts lis.
.. 41
Vue comportementale Ou control-flow. Dfinit les dpendances entre processus et donc lordre
dans lequel ces processus sont excuts. Est parfois assimil la vue
fonctionnelle.
.. 41
Vue des ressources ou vue oprationnelle. Elle spcifie les outils ou les systmes permettant
la ralisation du processus en dcrivant les moyens humains et matriels
ncessaires, ainsi que le mode de gestion de ces ressources.
.. 41
Vue fonctionnelle Description des processus et de leurs structures. Elle identifie les noms,
buts et actions des processus.
.. 41
Vue informationnelle ou data-flow. Cette vue indique quels sont les documents et donnes
utiliss chaque tape dun processus. Elle dcrit les objets du systme,
leurs relations et leurs diffrents tats possibles.
.. 41
Vue organisationnelle Dfinit les agents responsables et aptes excuter le processus. .. 41
190 EPILOGUE

W
Workflow Automatisation totale ou en partie des processus mtier, ou les
documents, informations ou tches sont distribus dun participant un
autre selon un ensemble de rgles procdurales.
.. 62
15.2 TRADUCTION DES TERMES ANGLOPHONES
La liste suivante prsente une traduction ou du moins une quivalence en franais des diffrents
termes anglophones rencontrs tout au long du manuscrit.
#
2 Tracks Unified Process Dmarche en Y
A
As-is Processus existant
As-wish Processus dsir
Atlas Transformation Language Langage de transformation ATLAS
B
Back-office Arrire-boutique
Block-Flow Diagram Diagramme de procds prliminaire
Bloc-oriented Orient en bloc
Bottom-up Approche ascendante
BPMN Common Core Noyau commun de BPMN
BPMN Extended Core Noyau tendu de BPMN
Business Activity Monitoring Supervision des processus mtier
Business Process Analysis Analyse des processus mtier
Business Process Diagram Diagramme de processus mtier
Business Process Implementation Implmentation des processus mtier
Business Process Management Ingnierie des processus mtier
Business Process Management Suite Suite doutils ddie lingnierie des processus
mtier
Business Process Modelling Modlisation des processus mtier
Business Rules Management Gestion des rgles mtier
Business Rules Management System Systme de gestion des rgles mtier
C
Computation Independent Model Modle mtier indpendant de linformatisation
Computer-Aided Modelling and
Process Design
Conception et modlisation des processus assistes
par ordinateur
Computer Aided Molecular Design Conception molculaire assiste par ordinateur
Control-flow Flux de contrle
D
Data flow Flux de donnes
Diagnosis Diagnostique
Document Type Definition Dfinition de type de document
Domain-Specific Modeling Language Langage de modlisation ddi un domaine
spcifique
15. ANNEXES 191

E
Enterprise Application Integration Intgration dApplication dEntreprise
F
Framework Cadre
H
Human-centric Bas sur lhumain
I
Integration-centric Bas sur intgration
K
Key Performance Indicators Indicateur cl de performance
L
Legacy software Logiciel hrit
M
Management Gestion ou ingnierie
Model Driven Architecture Architecture dirige par les modles
Model portability conformance class Classe de conformit de la portabilit du modle
Model-Driven Engineering Ingnierie dirige par les modles
Model-Driven Interoperability Interoprabilit dirige par les modles
P
Pattern Patron (au sens de modle rutilisable )
Piping and Instrumentation Diagram Schma tuyauterie et instrumentation
Platform Independent Model Modle dun systme mtier indpendant de la
plateforme technologique
Platform Model Modle gnrique de la plateforme technologique
Platform Specific Model Modle spcifique de la plateforme technologique
Process Design Conception des processus
Process-driven engineering Ingnierie dirig par les processus
Process Enactment Promulgation des processus (au sens
application/excution)
Process Systems Engineering Ingnierie des systmes de procds
Process-Flow Sheet Schma de principe de procd
S
Sequence-flow Flux squentiel
Strategic Alignment Model Modle dalignement stratgique
System Configuration Configuration du systme
T
To-be Processus cible
Top-down Approche descendante
192 EPILOGUE

U
Unified Enterprise Modeling Language Langage unifi de modlisation dentreprise
Unit operation Opration unitaire
W
Workflow Workflow, automatisation des processus
Workflow Management Coalition Coalition de gestion de workflow
Workflow Management System Systme de workflow
15.3 ACRONYMES
#
2TUP . 2 Track Unified Process
A
ARIS . Architecture of Integrated Information Systems
AS . Action Spcifique
B
BAM . Business Activity Monitoring
BFD . Block-Flow Diagram
BPA . Business Process Analysis
BPD . Business Process Diagram
BPEL . Business Process Execution Language
BPI . Business Process Implementation
BPM . Business Process Management
BPMN . Business Process Modeling Notation
BPMS . Business Process Management Suite
BPMS-HC . Business Process Management Suite Human Centric
BPMS-IC . Business Process Management Suite Integration Centric
C
CAMD . Computer Aided Molecular Design
CAPE . Computer-Aided Process Engineering
CIM . Computational Independant Model
D
DSML . Domain-Specific Modeling Language
DTD . Document Type Definition
E
EAI . Enterprise Application Integration
EEML . Extended Enterprise Modeling Language
EMF . Eclipse Modeling Framework
EMOF . Eclipse Meta-Object Facility
ERP . Enterprise Resource Planning
G
GDR . Groupe De Recherche
I
I3 . Information-Interaction-Intelligence
IDM . Ingnierie Dirige par les Modles
IEM . Integrated Enterprise Modeling
15. ANNEXES 193

IESI . Ingnierie dEntreprise et des Systmes dInformation
ISO . International Organization for Standardization
J
J2EE . Java Enterprise Edition
K
KPI . Key Performance Indicator
M
MACS . Modlisation, Analyse et Conduite des Systmes Dynamiques
MDA . Model-Driven Architecture
MDI . Model-Driven Interoperability
MME . Mthode de Modlisation dEntreprise
MOF . Meta-Object Facility
O
OCL . Object Constraint Language
OMG . Object Management Group
P
PFS . Process-Flow Sheet
PIM . Platform-Independant Model
PM . Platform Model
PSE . Process Systems Engineering
PSM . Platform Specific Model
S
SAM . Strategic Alignment Model
SCALP . Solution pour la Cohrence et lALignement des Processus
SGBD . Systme de Gestion de Base de Donnes
SI . Systme dInformation
SIC . Systme dInformation Collaboratif
SITI . Systme et Technologies dInformation
T
TI . Technologie dInformation
U
UEML . Unified Enterprise Modelling Language
UML . Unified Modeling Language
W
WfMC . Workflow Management Coalition
WFMS . Workflow Management System
X
XMI . XML Metadata Interchange
XML . eXtensible Markup Language
XPDL . XML Process Definition Language
XSD . XML Schema
XSLT . eXtensible Stylesheet Language Transformation

194 EPILOGUE

15.4 DEMONSTRATION : EXTRAITS DE FICHIERS
15.4.1
Extrait du fichier m
BPA
<?xml version="1.0" encoding="UTF-8"?>
<bpmn:BpmnDiagram xmlns:bpmn="http://ensiacet.org/lgc-psi/bpmn" xmlns:xmi="http://www.omg.org/XMI"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmi:version="2.0" xmi:id="_VbJHkO_0Ed-zNql9Y599ag" iD="_VbIggO_0Ed-zNql9Y599ag"
xsi:schemaLocation="http://ensiacet.org/lgc-psi/bpmn ../../metamodels/BPA/intalio.ecore">
<pools xmi:type="bpmn:Pool" xmi:id="_VcnHMe_0Ed-zNql9Y599ag" iD="_VcnHMO_0Ed-zNql9Y599ag"
name="Dpartement Beaut et Industrie">
<eAnnotations xmi:type="ecore:EAnnotation" xmi:id="_wx7yMO_3Ed-zNql9Y599ag" source="executablepool">
<details xmi:type="ecore:EStringToStringMapEntry" xmi:id="_wx7yMe_3Ed-zNql9Y599ag" key="poolIsExecutable"
value="false" />
</eAnnotations>
<lanes xmi:type="bpmn:Lane" xmi:id="_acjL8e_0Ed-zNql9Y599ag" iD="_acjL8O_0Ed-zNql9Y599ag" name="Equipe
Service Qualit" activities="_VdM9EO_0Ed-zNql9Y599ag _jSob0e_0Ed-zNql9Y599ag _3Bkroe_0Ed-zNql9Y599ag
_erHose_1Ed-zNql9Y599ag _qgbCwe_1Ed-zNql9Y599ag">
<vertices xmi:type="bpmn:Activity" xmi:id="_VdM9EO_0Ed-zNql9Y599ag" iD="_VdMWAO_0Ed-zNql9Y599ag"
outgoingEdges="_3BqLMe_0Ed-zNql9Y599ag" incomingEdges="_j5NToO_0Ed-zNql9Y599ag" name="Raliser
prlvement " lanes="_acjL8e_0Ed-zNql9Y599ag" activityType="Task">
<m_BPA x="118" y="18" height="61" width="107" xmi_id="_VdM9EO_0Ed-zNql9Y599ag" />
</vertices>
<vertices xmi:type="bpmn:Activity" xmi:id="_jSob0e_0Ed-zNql9Y599ag" iD="_jSob0O_0Ed-
zNql9Y599ag" outgoingEdges="_j5NToO_0Ed-zNql9Y599ag" lanes="_acjL8e_0Ed-zNql9Y599ag"
activityType="EventStartEmpty">
<m_BPA x="38" y="32" height="null" width="null" xmi_id="_jSob0e_0Ed-zNql9Y599ag" />
</vertices>
<vertices xmi:type="bpmn:Activity" xmi:id="_3Bkroe_0Ed-zNql9Y599ag" iD="_3BkroO_0Ed-zNql9Y599ag"
outgoingEdges="_erW5Qe_1Ed-zNql9Y599ag" incomingEdges="_3BqLMe_0Ed-zNql9Y599ag" name="Contrler
prlvement" lanes="_acjL8e_0Ed-zNql9Y599ag" activityType="Task">
<m_BPA x="274" y="18" height="null" width="106" xmi_id="_3Bkroe_0Ed-zNql9Y599ag" />
</vertices>
<vertices xmi:type="bpmn:Activity" xmi:id="_erHose_1Ed-zNql9Y599ag" iD="_erHosO_1Ed-zNql9Y599ag"
outgoingEdges="_qggiUe_1Ed-zNql9Y599ag _4Hv0Ee_1Ed-zNql9Y599ag" incomingEdges="_erW5Qe_1Ed-
zNql9Y599ag" name="Etat du lot ?" lanes="_acjL8e_0Ed-zNql9Y599ag _a5b8Qe_0Ed-zNql9Y599ag"
activityType="GatewayDataBasedExclusive">
<m_BPA x="420" y="22" height="null" width="75" xmi_id="_erHose_1Ed-zNql9Y599ag" />
</vertices>
<vertices xmi:type="bpmn:Activity" xmi:id="_qgbCwe_1Ed-zNql9Y599ag" iD="_qgbCwO_1Ed-zNql9Y599ag"
outgoingEdges="_n9IUse_3Ed-zNql9Y599ag" incomingEdges="_qggiUe_1Ed-zNql9Y599ag" name="Passer en suivi de
lots bloqus" lanes="_acjL8e_0Ed-zNql9Y599ag" activityType="Task">
<m_BPA x="538" y="18" height="null" width="114" xmi_id="_qgbCwe_1Ed-zNql9Y599ag" />
</vertices>
<m_BPA x="null" y="5" height="132" width="20" xmi_id="_acjL8e_0Ed-zNql9Y599ag" />
</lanes>
<lanes xmi:type="bpmn:Lane" xmi:id="_a5b8Qe_0Ed-zNql9Y599ag" iD="_a5b8QO_0Ed-zNql9Y599ag"
name="Equipe Conditionnnement" activities="_4Hq7ke_1Ed-zNql9Y599ag _B0jQke_2Ed-zNql9Y599ag _GPvpge_2Ed-
zNql9Y599ag _MW3Ywe_2Ed-zNql9Y599ag _PX79Ee_2Ed-zNql9Y599ag _n5SL8e_2Ed-zNql9Y599ag _rD5Gwe_2Ed-
zNql9Y599ag _tjtYIe_2Ed-zNql9Y599ag _8TN5ge_2Ed-zNql9Y599ag __S9BEe_2Ed-zNql9Y599ag _DqK48e_3Ed-
zNql9Y599ag _MQZu8e_3Ed-zNql9Y599ag _Rh7S8e_3Ed-zNql9Y599ag _Z__EYO_3Ed-zNql9Y599ag _iMRJUe_3Ed-
zNql9Y599ag _mLc7se_3Ed-zNql9Y599ag _qKVMEO_3Ed-zNql9Y599ag _erHose_1Ed-zNql9Y599ag">
<vertices xmi:type="bpmn:Activity" xmi:id="_4Hq7ke_1Ed-zNql9Y599ag" iD="_4Hq7kO_1Ed-zNql9Y599ag"
outgoingEdges="_B0owIe_2Ed-zNql9Y599ag" incomingEdges="_4Hv0Ee_1Ed-zNql9Y599ag" name="Rceptionner le
lot" lanes="_a5b8Qe_0Ed-zNql9Y599ag" activityType="Task">
<m_BPA x="489" y="258" height="null" width="null" xmi_id="_4Hq7ke_1Ed-zNql9Y599ag" />
</vertices>

Figure 92. Extrait du fichier m
BPA

15. ANNEXES 195

15.4.2 Extrait du fichier mBPI
<?xml version="1.0" encoding="UTF-8"?>
<openerp:Data xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" xmlns:openerp="http://openerp/1.0" xsi:schemaLocation="http://openerp/1.0
../../metamodels/BPI/openERP.ecore" name="ReintegProcess" version="v1.0" author="ULMER Jean-Stphane">
<activities id="_jSob0O_0Ed-zNql9Y599ag" wkf_id="wkf0" name="Start" flow_start="true"/>
<activities id="_VdMWAO_0Ed-zNql9Y599ag" wkf_id="wkf0" name="Raliser Prlvement" kind="function"
action="true"/>
<activities id="_3BkroO_0Ed-zNql9Y599ag" wkf_id="wkf0" name="Contrler Prlvement" kind="function"/>
<activities id="_erHosO_1Ed-zNql9Y599ag" wkf_id="wkf0" name="Etat du lot?" split_mode="XOR"/>
<activities id="_qgbCwO_1Ed-zNql9Y599ag" wkf_id="wkf0" name="Passer en suivi de lots bloqus"/>
<activities id="_4Hq7kO_1Ed-zNql9Y599ag" wkf_id="wkf0" name="Rceptionner le lot" kind="function"/>
<activities id="_B0jQkO_2Ed-zNql9Y599ag" wkf_id="wkf0" name="Type?" split_mode="XOR"/>
<activities id="_GPvpgO_2Ed-zNql9Y599ag" wkf_id="wkf0" name="Traiter produits semi-finis" kind="function"/>
<activities id="_MW3YwO_2Ed-zNql9Y599ag" wkf_id="wkf0" name="Traiter en interne" kind="function"/>
<activities id="_8TN5gO_2Ed-zNql9Y599ag" wkf_id="wkf0" name="default" join_mode="XOR"/>
<activities id="_qKUlAO_3Ed-zNql9Y599ag" wkf_id="wkf0" name="End" flow_stop="true"/>
<activities id="_Z_-dUO_3Ed-zNql9Y599ag" wkf_id="wkf0" name="Traiter produits testeurs" kind="function"/>
<activities id="_iMRJUO_3Ed-zNql9Y599ag" wkf_id="wkf0" name="default" join_mode="XOR"/>
<activities id="__S9BEO_2Ed-zNql9Y599ag" wkf_id="wkf0" name="Mettre en conformit" kind="function"/>
<activities id="_mLc7sO_3Ed-zNql9Y599ag" wkf_id="wkf0" name="Disponibilit palette?" split_mode="XOR"/>
<activities id="_Rh7S8O_3Ed-zNql9Y599ag" wkf_id="wkf0" name="Charger palette" kind="function"/>
<activities id="_MQZu8O_3Ed-zNql9Y599ag" wkf_id="wkf0" name="Attendre palette disponible"/>
<activities id="_PX79EO_2Ed-zNql9Y599ag" wkf_id="wkf0" name="Traiter produits ventes" kind="function"/>
<activities id="_n5SL8O_2Ed-zNql9Y599ag" wkf_id="wkf0" name="Format sur ligne?" split_mode="XOR"/>
<activities id="_rD5GwO_2Ed-zNql9Y599ag" wkf_id="wkf0" name="Recellophaner produits" kind="function"/>
<activities wkf_id="wkf0" name="Attendre ligne disponible" kind="function"/>
<transitions id="_j5MskO_0Ed-zNql9Y599ag" act_from="_jSob0O_0Ed-zNql9Y599ag" act_to="_VdMWAO_0Ed-
zNql9Y599ag" role_id=""Equipe Service Qualit"" condition="true"/>
<transitions id="_3BqLMO_0Ed-zNql9Y599ag" act_from="_VdMWAO_0Ed-zNql9Y599ag" act_to="_3BkroO_0Ed-
zNql9Y599ag" role_id=""Equipe Service Qualit"" condition=""/>
<transitions id="_erW5QO_1Ed-zNql9Y599ag" act_from="_3BkroO_0Ed-zNql9Y599ag" act_to="_erHosO_1Ed-
zNql9Y599ag" role_id=""Equipe Service Qualit""/>
<transitions id="_qggiUO_1Ed-zNql9Y599ag" act_from="_erHosO_1Ed-zNql9Y599ag" act_to="_qgbCwO_1Ed-
zNql9Y599ag" role_id=""Equipe Service Qualit"" condition="('lot bloqu') == true"/>
<transitions id="_4Hv0EO_1Ed-zNql9Y599ag" act_from="_qgbCwO_1Ed-zNql9Y599ag" act_to="_8TN5gO_2Ed-
zNql9Y599ag" role_id=""Equipe Service Qualit""/>
<transitions id="_B0owIO_2Ed-zNql9Y599ag" act_from="_erHosO_1Ed-zNql9Y599ag" act_to="_4Hq7kO_1Ed-
zNql9Y599ag" role_id=""Equipe Service Qualit"" condition="('lot bloqu') != true"/>
<transitions id="_GP1JEO_2Ed-zNql9Y599ag" act_from="_B0jQkO_2Ed-zNql9Y599ag" act_to="_GPvpgO_2Ed-
zNql9Y599ag" role_id=""Equipe Conditionnement"" condition="('default')"/>
<transitions id="_MW9fYO_2Ed-zNql9Y599ag" act_from="_GPvpgO_2Ed-zNql9Y599ag" act_to="_MW3YwO_2Ed-
zNql9Y599ag" role_id=""Equipe Conditionnement""/>
<transitions id="_PYA1kO_2Ed-zNql9Y599ag" act_from="_MW3YwO_2Ed-zNql9Y599ag" act_to="_8TN5gO_2Ed-
<transitions id="_n5XrgO_2Ed-zNql9Y599ag" act_from="_B0jQkO_2Ed-zNql9Y599ag" act_to="_Z_-dUO_3Ed-
<transitions id="_rD-mUO_2Ed-zNql9Y599ag" act_from="_Z_-dUO_3Ed-zNql9Y599ag" act_to="_8TN5gO_2Ed-
zNql9Y599ag" role_id=""Equipe Conditionnement"" condition=""/>
<transitions id="_tjy3sO_2Ed-zNql9Y599ag" act_from="_8TN5gO_2Ed-zNql9Y599ag" act_to="__S9BEO_2Ed-
<transitions id="_2sloMO_2Ed-zNql9Y599ag" act_from="__S9BEO_2Ed-zNql9Y599ag" act_to="_mLc7sO_3Ed-
Figure 93.Extrait du fichier m
BPI

196 EPILOGUE

15.4.3 Fichiers constituant le module OpenERP
Les diffrents fichiers composant le module OpenERP trait dans la partie D. Mise en uvre sont
prsents dans cette section. A titre de rappel, leurs rles dtaills dans le Tableau 25 ci-dessous :
Tableau 25. Noms et rles des fichiers du module OpenERP
Nom du fichier Rle
__init__.py Fichier de dmarrage indiquant les imports du module
__terp__.py Fichier indiquant la nomenclature du module
ReintegProcess.py Description fonctionnelle (classes et fonctions)
ReintegProcess_view..xml Description de linterface
ReintegProcess_workflow..xml Description du squencement dactivits

Figure 94. Fichier __init__.py

Figure 95. Fichier __terp__.py

i mpor t Rei nt egPr ocess

{
'name' : 'ReintegProcess',
'version' : 'v1.0',
'author' : 'ULMER Jean-Stphane',
'depends' : [ 'base'] ,
'update_xml' : [
'ReintegProcess_workflow.xml', 'ReintegProcess_view.xml'] ,
'installable': Tr ue,
'active': Fal se,
}
15. ANNEXES 197

f r omosv i mpor t f i el ds, osv
cl ass Rei nt egPr ocess_Rei nt egPr ocess ( osv. osv) :
_name = "ReintegProcess.ReintegProcess"
_col umns = {
'user_id': f i el ds. many2one( 'res.users', 'Utilisateur', r equi r ed=Tr ue,
r eadonl y=Tr ue) ,
'description': f i el ds. t ext ( 'Description', r equi r ed=Tr ue, hel p='Remarques ou
commentaires') ,
'state': f i el ds. sel ect i on( [ ( '_jSob0O_0Ed-
zNql9Y599ag', 'Start') , ( '_VdMWAO_0Ed-zNql9Y599ag', 'Raliser Prlvement') , ( '_3BkroO_0Ed-
zNql9Y599ag', 'Contrler Prlvement') , ( '_erHosO_1Ed-zNql9Y599ag', 'Etat du
lot?') , ( '_qgbCwO_1Ed-zNql9Y599ag', 'Passer en suivi de lots bloqus') , ( '_4Hq7kO_1Ed-
zNql9Y599ag', 'Rceptionner le lot') , ( '_B0jQkO_2Ed-zNql9Y599ag', 'Type?') , ( '_GPvpgO_2Ed-
zNql9Y599ag', 'Traiter produits semi-finis') , ( '_MW3YwO_2Ed-zNql9Y599ag', 'Traiter en
interne') , ( '_8TN5gO_2Ed-zNql9Y599ag', 'default') , ( '_qKUlAO_3Ed-zNql9Y599ag', 'End') , ( '_Z_-
dUO_3Ed-zNql9Y599ag', 'Traiter produits testeurs') , ( '_iMRJUO_3Ed-
zNql9Y599ag', 'default') , ( '__S9BEO_2Ed-zNql9Y599ag', 'Mettre en conformit') , ( '_mLc7sO_3Ed-
zNql9Y599ag', 'Disponibilit palette?') , ( '_Rh7S8O_3Ed-zNql9Y599ag', 'Charger
palette') , ( '_MQZu8O_3Ed-zNql9Y599ag', 'Attendre palette disponible') , ( '_PX79EO_2Ed-
zNql9Y599ag', 'Traiter produits ventes') , ( '_n5SL8O_2Ed-zNql9Y599ag', 'Format sur
ligne?') , ( '_rD5GwO_2Ed-zNql9Y599ag', 'Recellophaner produits') , ( 'null', 'Attendre ligne
disponible') , ] , 'Etat du module', r eadonl y=Tr ue) ,
}
_def aul t s = {
'user_id': l ambda self, cr , ui d, cont ext : ui d,
'state': l ambda *a: '('_j Sob0O_0Ed- zNql 9Y599ag','St ar t '),'
}

def Rei nt egPr ocess__j Sob0O_0Ed- zNql 9Y599ag( self, cr , ui d, i ds) :
self. wr i t e( cr , ui d, i ds, { 'state' : '_jSob0O_0Ed-zNql9Y599ag' })
r et ur n Tr ue
def Rei nt egPr ocess__VdMWAO_0Ed- zNql 9Y599ag( self, cr , ui d, i ds) :
self. wr i t e( cr , ui d, i ds, { 'state' : '_VdMWAO_0Ed-zNql9Y599ag' })
r et ur n Tr ue
def Rei nt egPr ocess__3Bkr oO_0Ed- zNql 9Y599ag( self, cr , ui d, i ds) :
self. wr i t e( cr , ui d, i ds, { 'state' : '_3BkroO_0Ed-zNql9Y599ag' })
r et ur n Tr ue
def Rei nt egPr ocess__er HosO_1Ed- zNql 9Y599ag( self, cr , ui d, i ds) :
self. wr i t e( cr , ui d, i ds, { 'state' : '_erHosO_1Ed-zNql9Y599ag' })
r et ur n Tr ue
def Rei nt egPr ocess__qgbCwO_1Ed- zNql 9Y599ag( self, cr , ui d, i ds) :
self. wr i t e( cr , ui d, i ds, { 'state' : '_qgbCwO_1Ed-zNql9Y599ag' })
r et ur n Tr ue
def Rei nt egPr ocess__4Hq7kO_1Ed- zNql 9Y599ag( self, cr , ui d, i ds) :
self. wr i t e( cr , ui d, i ds, { 'state' : '_4Hq7kO_1Ed-zNql9Y599ag' })
r et ur n Tr ue
def Rei nt egPr ocess__B0j QkO_2Ed- zNql 9Y599ag( self, cr , ui d, i ds) :
self. wr i t e( cr , ui d, i ds, { 'state' : '_B0jQkO_2Ed-zNql9Y599ag' })
r et ur n Tr ue
def Rei nt egPr ocess__GPvpgO_2Ed- zNql 9Y599ag( self, cr , ui d, i ds) :
self. wr i t e( cr , ui d, i ds, { 'state' : '_GPvpgO_2Ed-zNql9Y599ag' })
r et ur n Tr ue
def Rei nt egPr ocess__MW3YwO_2Ed- zNql 9Y599ag( self, cr , ui d, i ds) :
self. wr i t e( cr , ui d, i ds, { 'state' : '_MW3YwO_2Ed-zNql9Y599ag' })
r et ur n Tr ue
def Rei nt egPr ocess__8TN5gO_2Ed- zNql 9Y599ag( self, cr , ui d, i ds) :
self. wr i t e( cr , ui d, i ds, { 'state' : '_8TN5gO_2Ed-zNql9Y599ag' })
r et ur n Tr ue
def Rei nt egPr ocess__qKUl AO_3Ed- zNql 9Y599ag( self, cr , ui d, i ds) :
self. wr i t e( cr , ui d, i ds, { 'state' : '_qKUlAO_3Ed-zNql9Y599ag' })
r et ur n Tr ue
Figure 96.Extrait du fichier ReintegProcess.py

198 EPILOGUE

<?xml ver si on="1.0" encodi ng="UTF-8"?>
<opener p>
<dat a>
<r ecor d model ="workflow" i d="wkf0_ReintegProcess">
<f i el d name="name">Rei nt egPr ocess. wkf 0</ f i el d>
<f i el d name="osv">Rei nt egPr ocess. Rei nt egPr ocess</ f i el d>
<f i el d name="on_create">Tr ue</ f i el d>
</ r ecor d>
<r ecor d model ="workflow.activity" i d="_jSob0O_0Ed-zNql9Y599ag">
<f i el d name="wkf_id" r ef ="wkf0_ReintegProcess" / >
<f i el d name="name">St ar t </ f i el d>
<f i el d name="flow_start">t r ue</ f i el d>
</ r ecor d>
<r ecor d model ="workflow.activity" i d="_VdMWAO_0Ed-zNql9Y599ag">
<f i el d name="name">Ral i ser Pr l vement </ f i el d>
<f i el d name="kind">f unct i on</ f i el d>
<f i el d name="action">t r ue</ f i el d>
</ r ecor d>
<r ecor d model ="workflow.activity" i d="_3BkroO_0Ed-zNql9Y599ag">
<f i el d name="name">Cont r l er Pr l vement </ f i el d>
</ r ecor d>
<r ecor d model ="workflow.activity" i d="_erHosO_1Ed-zNql9Y599ag">
<f i el d name="name">Et at du l ot ?</ f i el d>
<f i el d name="split_mode">XOR</ f i el d>
</ r ecor d>
<r ecor d model ="workflow.activity" i d="_qgbCwO_1Ed-zNql9Y599ag">
<f i el d name="name">Passer en sui vi de l ot s bl oqus</ f i el d>
</ r ecor d>
<r ecor d model ="workflow.activity" i d="_4Hq7kO_1Ed-zNql9Y599ag">
<f i el d name="name">Rcept i onner l e l ot </ f i el d>
</ r ecor d>
Figure 97. Extrait du fichier ReintegProcess_workflow.xml

15. ANNEXES 199

<?xml ver si on="1.0" encodi ng="UTF-8"?>
<opener p>
<dat a>
<menui t emname="Modules SCALP" i d="menu_scalp" i con="STOCK_PREFERENCES" / >
<r ecor d model ="ir.ui.view" i d="ReintegProcess_form_view">
<f i el d name="name">Rei nt egPr ocess. f or m</ f i el d>
<f i el d name="model">Rei nt egPr ocess. Rei nt egPr ocess</ f i el d>
<f i el d name="type">f or m</ f i el d>
<f i el d name="arch" t ype="xml">
<f or mst r i ng="ReintegProcess">
<f i el d name="user_id" sel ect ="1" / >
<f i el d name="description" col span="4" sel ect ="2" wi dget ="text_wiki" / >
<f i el d name="state" sel ect ="2" / >
<gr oup col span="2" col ="20">
<but t on name="_VdMWAO_0Ed-zNql9Y599ag" st r i ng="raliser prlvement"
st at es="Start" / >
<but t on name="_3BkroO_0Ed-zNql9Y599ag" st r i ng="contrler prlvement"
st at es="Raliser Prlvement" / >
<but t on name="_erHosO_1Ed-zNql9Y599ag" st r i ng="etat du lot?"
st at es="Contrler Prlvement" / >
<but t on name="_qgbCwO_1Ed-zNql9Y599ag" st r i ng="passer en suivi de lots
bloqus" st at es="Etat du lot?" / >
<but t on name="_4Hq7kO_1Ed-zNql9Y599ag" st r i ng="rceptionner le lot"
st at es="Passer en suivi de lots bloqus" / >
<but t on name="_B0jQkO_2Ed-zNql9Y599ag" st r i ng="type?" st at es="Rceptionner le
lot" / >
<but t on name="_GPvpgO_2Ed-zNql9Y599ag" st r i ng="traiter produits semi-finis"
st at es="Type?" / >
<but t on name="_MW3YwO_2Ed-zNql9Y599ag" st r i ng="traiter en interne"
st at es="Traiter produits semi-finis" / >
<but t on name="_8TN5gO_2Ed-zNql9Y599ag" st r i ng="default" st at es="Traiter en
interne" / >
<but t on name="_qKUlAO_3Ed-zNql9Y599ag" st r i ng="end" st at es="default" / >
<but t on name="_Z_-dUO_3Ed-zNql9Y599ag" st r i ng="traiter produits testeurs"
st at es="End" / >
<but t on name="_iMRJUO_3Ed-zNql9Y599ag" st r i ng="default" st at es="Traiter
produits testeurs" / >
<but t on name="__S9BEO_2Ed-zNql9Y599ag" st r i ng="mettre en conformit"
st at es="default" / >
<but t on name="_mLc7sO_3Ed-zNql9Y599ag" st r i ng="disponibilit palette?"
st at es="Mettre en conformit" / >
<but t on name="_Rh7S8O_3Ed-zNql9Y599ag" st r i ng="charger palette"
st at es="Disponibilit palette?" / >
<but t on name="_MQZu8O_3Ed-zNql9Y599ag" st r i ng="attendre palette disponible"
st at es="Charger palette" / >
<but t on name="_PX79EO_2Ed-zNql9Y599ag" st r i ng="traiter produits ventes"
st at es="Attendre palette disponible" / >
<but t on name="_n5SL8O_2Ed-zNql9Y599ag" st r i ng="format sur ligne?"
st at es="Traiter produits ventes" / >
<but t on name="_rD5GwO_2Ed-zNql9Y599ag" st r i ng="recellophaner produits"
st at es="Format sur ligne?" / >
<but t on name="default" st r i ng="attendre ligne disponible"
st at es="Recellophaner produits" / >
</ gr oup>
</ f or m>
</ f i el d>
</ r ecor d>
<r ecor d model ="ir.ui.view" i d="ReintegProcess_tree_view">
<f i el d name="name">Rei nt egPr ocess. t r ee</ f i el d>
<f i el d name="model">Rei nt egPr ocess. Rei nt egPr ocess</ f i el d>

Figure 98. Extrait du fichier ReintegProcess_view.xml
200 EPILOGUE

15.4.4 Diagramme Intalio obtenu en fin de seconde phase

Figure 99. Diagramme Intalio obtenue en fin de seconde phase

15. ANNEXES 201

15.4.5 Diagramme Intalio modifi au dbut de la troisime phase

Figure 100. Diagramme Intalio modifi au dbut de la troisime phase

15.5 SOMMAIRE DETAILLE
A. PREAMBULE ....................................................................................................................................................... 15
1. INTRODUCTION ....................................................................................................................................................17
1.1 CADRE DES TRAVAUX DE RECHERCHE .......................................................................................................................18
1.2 PRESENTATION DU MANUSCRIT ..............................................................................................................................19
1.2.1 Dmarche propose ............................................................................................................................ 19
1.2.2 Typologie adopte .............................................................................................................................. 20
2. CONTEXTE ET PROBLEMATIQUE ................................................................................................................................23
2.1 CONTEXTE ........................................................................................................................................................24
2.1.1 Naissance et importance des stratgies SITI et mtier.......................................................................... 24
2.1.2 Besoin dun alignement entre stratgie mtier et stratgie SITI ........................................................... 24
2.1.3 Alignement stratgique, alignement oprationnel ............................................................................... 25
2.1.4 Emergence dun nouveau domaine de lingnierie des SI...................................................................... 26
2.2 PROBLEMATIQUE ...............................................................................................................................................27
2.2.1 Alignement oprationnel, intgration fonctionnelle, cohrence, ....................................................... 27
2.2.2 Cycles de vie dapplications et de technologies asynchrones ................................................................ 27
2.2.3 De la difficult maintenir lalignement .............................................................................................. 28
2.3 OBJECTIFS DE RECHERCHE .....................................................................................................................................29
2.3.1 Contributions ...................................................................................................................................... 29
2.3.2 Rsultats principaux ............................................................................................................................ 29
B. CADRE METHODOLOGIQUE ................................................................................................................................ 31
3. DE LENTREPRISE AU PROCESSUS ...............................................................................................................................33
3.1 ENTREPRISE ......................................................................................................................................................34
3.1.1 Dfinition ............................................................................................................................................ 34
3.1.2 Entreprise, un systme de systmes ..................................................................................................... 35
3.2 SYSTEME DINFORMATION ....................................................................................................................................36
3.3 MODELISATION DENTREPRISE ...............................................................................................................................38
3.4 CADRE DE MODELISATION DENTREPRISE ..................................................................................................................39
3.4.1 Cycle de vie ......................................................................................................................................... 40
3.4.2 Structure et comportement ................................................................................................................. 41
3.4.3 Degr de particularisation ................................................................................................................... 41
3.5 CONCLUSION .....................................................................................................................................................42
4. NOTIONSAUTOUR DU TERME PROCESSUS .............................................................................................................43
204 EPILOGUE

4.1 PROCESSUS .......................................................................................................................................................44
4.2 PROCESSUS MTIER .............................................................................................................................................45
4.2.1 Processus mtier et SI ......................................................................................................................... 47
4.2.2 Processus mtier, processus fonctionnel, procdure ............................................................................. 48
4.3 CYCLE DE VIE ET ACTEURS .....................................................................................................................................49
4.3.1 Cycle de vie ......................................................................................................................................... 49
4.3.2 Acteurs ............................................................................................................................................... 49
4.4 MODELISATION PAR LES PROCESSUS : IMPORTANCE DE LA VUE FONCTIONNELLE ..................................................................50
4.5 CONCLUSION .....................................................................................................................................................51
5. INGENIERIE ET ARCHITECTURE DIRIGEESPAR LESMODELES .............................................................................................53
5.1 INGENIERIE DIRIGEE PAR LES MODELES .....................................................................................................................54
5.1.1 Systme rel, modle, mtamodle ..................................................................................................... 54
5.1.2 Processus de tissage de conception ..................................................................................................... 55
5.2 ARCHITECTURE DIRIGEE PAR LES MODELES.................................................................................................................55
5.2.1 Rles des CIM, PIM et PSM .................................................................................................................. 56
5.2.2 MOF, UML, XMI .................................................................................................................................. 57
5.2.3 Limite du MDA .................................................................................................................................... 58
5.3 CONCLUSION .....................................................................................................................................................59
6. INGENIERIE DES PROCESSUSMETIER ...........................................................................................................................61
6.1 DE LA GESTION DU WORKFLOW A LA GESTION DES PROCESSUS METIER ..............................................................................62
6.2 LE CYCLE DE VIE DU PROCESSUS SELON LAPPROCHE BPM .............................................................................................64
6.2.1 Business Process Analysis, BPA ............................................................................................................ 65
6.2.2 Business Process Implementation, BPI ................................................................................................. 65
6.2.3 Business Activity Monitoring, BAM ...................................................................................................... 66
6.3 DU MDA AU BPM ............................................................................................................................................67
6.4 SUITES BPM .....................................................................................................................................................68
6.4.1 Une volution ncessaire..................................................................................................................... 68
6.4.2 Dfinition ............................................................................................................................................ 68
6.4.3 Structure ............................................................................................................................................. 70
6.4.4 Classification....................................................................................................................................... 70
6.4.5 Conclusion sur les BPMS ...................................................................................................................... 71
6.5 LES LIMITES DU BPM ..........................................................................................................................................72
6.6 CONCLUSION .....................................................................................................................................................72
C. DEFINITION DE LAPPROCHE............................................................................................................................... 75
7. DE LA NECESSITE DE LAPPROCHE ..............................................................................................................................77
15. ANNEXES 205

7.1 VERS UN ALIGNEMENT OPERATIONNEL .....................................................................................................................78
7.1.1 Synchronisation .................................................................................................................................. 79
7.1.2 Equivalence smantique ...................................................................................................................... 79
7.1.3 Cohrence intermodle ....................................................................................................................... 80
7.2 HETEROGENEITE ET DIFFERENTES ABSTRACTIONS .........................................................................................................81
7.2.1 Modle danalyse ................................................................................................................................ 81
7.2.2 Modle dimplmentation ................................................................................................................... 81
7.2.3 Deux domaines, deux visions : prmisses de lcart mtier-SITI ............................................................ 82
7.3 CONCEPTS ET APPROCHES POUR UNE GESTION AGILE....................................................................................................82
7.3.1 Utilisation de rgles mtier ................................................................................................................. 83
7.3.2 Facilit lvolution des plateformes ..................................................................................................... 83
7.3.3 Transformation entre modles : la ncessit du mtamodle ............................................................... 85
7.4 CONCLUSION .....................................................................................................................................................86
8. CARACTERISATION ................................................................................................................................................89
8.1 VERS UNE APPROCHE CENTREE PIVOT .......................................................................................................................90
8.2 VUES...............................................................................................................................................................91
8.3 GENERICITE ......................................................................................................................................................92
8.4 ACTEURS ..........................................................................................................................................................92
8.5 DONNEES .........................................................................................................................................................92
8.6 CONCLUSION .....................................................................................................................................................96
9. CONCEPTION .......................................................................................................................................................97
9.1 CONFORMITE ENTRE MODELE ET METAMODELE ..........................................................................................................98
9.1.1 Modle et ReprsentationDe () .................................................................................................... 98
9.1.2 Mtamodle et EstConformeA () ................................................................................................. 98
9.2 DE LA TRANSFORMATION DE MODELES BIDIRECTIONNELLES A LA NOTION DE PIVOT ............................................................ 100
9.2.1 Relation bidirectionnelle.................................................................................................................... 100
9.2.2 Fonctions de conformit constructive ................................................................................................ 101
9.3 TRANSFORMATIONS HORIZONTALES, TRANSFORMATIONS VERTICALES ET INTEROPERABILITE ................................................. 103
9.4 METAMODELE ET METAMODELES PIVOT ................................................................................................................. 104
9.5 DEFINITION DU METAMODELE PIVOT ..................................................................................................................... 107
9.5.1 Elments de modlisation des processus mtier................................................................................. 107
9.5.2 Famille dlments : Special .............................................................................................................. 111
9.5.3 Groupe Node .................................................................................................................................... 112
9.5.4 Groupe Edge ..................................................................................................................................... 113
9.5.5 Groupe Swimlane .............................................................................................................................. 114
9.5.6 Groupe Artefact ................................................................................................................................ 114
9.6 CARACTERISATION DES LIENS SEMANTIQUES ............................................................................................................ 115
206 EPILOGUE

9.6.1 Typologie des liens smantiques ........................................................................................................ 115
9.6.2 Exemple dquivalence smantique ................................................................................................... 115
9.7 FORMATION DES METAMODELES BPA ET BPI .......................................................................................................... 116
9.8 CONCLUSION ................................................................................................................................................... 117
D. MISE EN UVRE ............................................................................................................................................... 119
10. PLATEFORME SOLUTION POUR UNE COHERENCE ET UN ALIGNEMENT DESPROCESSUS- SCALP ............................................ 121
10.1 ARCHITECTURE GENERALE DE LA PLATEFORME SCALP ............................................................................................... 122
10.2 ENVIRONNEMENT PIVOT .................................................................................................................................... 122
10.2.1 Eclipse Modeling Framework ............................................................................................................. 122
10.2.2 Kermeta ............................................................................................................................................ 124
10.3 ENVIRONNEMENT DE MODELISATION ..................................................................................................................... 125
10.4 ENVIRONNEMENT DIMPLEMENTATION .................................................................................................................. 126
10.4.1 SI et ERP ........................................................................................................................................... 126
10.4.2 Ct technique .................................................................................................................................. 126
10.5 IMPLEMENTATION DES MAPPINGS ET TRANSFORMATIONS ........................................................................................... 129
10.5.1 Mtamodles BPA et BPI ................................................................................................................... 129
10.5.2 Pattern Visiteur ................................................................................................................................. 131
10.5.3 Mappings et transformations ............................................................................................................ 134
10.6 CONCLUSION ................................................................................................................................................... 134
11. DEMONSTRATION ............................................................................................................................................... 137
11.1 PRESENTATION DU PROCESSUS ETUDIE ................................................................................................................... 139
11.2 SCENARIO DE VALIDATION................................................................................................................................... 139
11.3 PREMIERE PHASE : DU DIAGRAMME DE PROCESSUS AU MODULE ERP............................................................................. 143
11.3.1 Du diagramme de processus Intalio vers un modle danalyse m
BPA
................................................... 143
11.3.2 Du modle danalyse vers le modle pivot ......................................................................................... 145
11.3.3 Du modle pivot vers le modle dimplmentation............................................................................. 147
11.3.4 Du modle dimplmentation vers le module OpenERP ...................................................................... 148
11.4 DEUXIEME PHASE : DU MODULE ERP AU DIAGRAMME DE PROCESSUS ............................................................................ 149
11.4.1 Modifications apportes ................................................................................................................... 149
11.4.2 Du module OpenERP vers le modle dimplmentation ...................................................................... 150
11.4.3 Du modle dimplmentation au diagramme de processus ................................................................ 151
11.5 TROISIEME PHASE : DU DIAGRAMME DE PROCESSUS AU MODULE ERP ........................................................................... 154
11.6 CONCLUSION ................................................................................................................................................... 155
12. INGENIERIE DES PROCESSUSAU SERVICE DE LINGENIERIE DESPROCEDES........................................................................... 157
12.1 NOTIONS AUTOUR DE LINGENIERIE DES PROCEDES ................................................................................................... 158
15. ANNEXES 207

12.2 VERS UNE APPROCHE PROCESSUS-PROCEDE ............................................................................................................. 159
12.3 CONCLUSION ................................................................................................................................................... 163
E. EPILOGUE ......................................................................................................................................................... 165
13. CONCLUSION ET PERSPECTIVES ............................................................................................................................... 167
13.1 CONCLUSION ................................................................................................................................................... 167
13.2 BILAN ............................................................................................................................................................ 168
13.2.1 Cadre mthodologique ...................................................................................................................... 168
13.2.2 Dfinition de lapproche .................................................................................................................... 168
13.2.3 Mise en uvre .................................................................................................................................. 169
13.3 SYNTHESE DES CONTRIBUTIONS ............................................................................................................................ 170
13.4 LIMITES ET PERSPECTIVES .................................................................................................................................... 171
13.4.1 Utilisation et utilit de la plateforme SCALP ....................................................................................... 171
13.4.2 Gnration de code et orchestration de services ................................................................................ 172
13.4.3 Alignement stratgique, alignement oprationnel ............................................................................. 172
13.4.4 Abstraction et interoprabilit .......................................................................................................... 172
13.4.5 Evolution de la plateforme SCALP ...................................................................................................... 173
13.4.6 Extension de lapproche SCALP au domaine Process Systems Engineering .......................................... 173
14. BIBLIOGRAPHIE .................................................................................................................................................. 175
15. ANNEXES .......................................................................................................................................................... 185
15.1 GLOSSAIRE ..................................................................................................................................................... 186
15.2 TRADUCTION DES TERMES ANGLOPHONES ............................................................................................................... 190
15.3 ACRONYMES ................................................................................................................................................... 192
15.4 DEMONSTRATION : EXTRAITS DE FICHIERS ............................................................................................................... 194
15.4.1
Extrait du fichier m
BPA
........................................................................................................................ 194
15.4.2 Extrait du fichier mBPI ....................................................................................................................... 195
15.4.3 Fichiers constituant le module OpenERP ............................................................................................ 196
15.4.4 Diagramme Intalio obtenu en fin de seconde phase ........................................................................... 200
15.4.5 Diagramme Intalio modifi au dbut de la troisime phase................................................................ 201
15.5 SOMMAIRE DETAILLE ......................................................................................................................................... 203

Tyu

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Tyu

Încărcat de

Drepturi de autor:

Formate disponibile

n vue de I'obtention du

UOC1OkA1 UL L'UH|vLkS|1L UL 1OULOUSL

100 C. DEFINITION DE LAPPROCHE

)est vraie (10)

S-ar putea să vă placă și