Modélisation conjointe de l infrastructure et des processus pour l administration pro-active de l entreprise distribuée

04 ISAL 0085 Ann´ee 2004

Mod´ elisation conjointe de

l’infrastructure et des processus pour l’administration pro-active de

l’entreprise distribu´ ee

TH` ESE

pr´esent´ee et soutenue publiquement le 10 d´ecembre 2004 devant L’Institut National des Sciences Appliqu´ees de Lyon

pour obtenir le

Grade de Docteur

(sp´ecialit´e informatique)

Ecole Doctorale Informatique et Information pour la Soci´et´e

par

Herv´ e MATHIEU

Jury

Rapporteurs : Pr. Dominique RIEU Pr. Herv´e PINGAUD Pr. Eric RONDEAU Examinateurs : Pr. Jo¨el FAVREL

Pr. Fr´ed´erique BIENNIER (Directeur de th`ese)

Laboratoire de Productique et d’Informatique des Syst`emes Manufacturiers

Remerciements

Un immense Merci `a Madame BIENNIER, pour son soutien, sa gentillesse, et son indulgence, et sans laquelle mes projets, qui j’esp`ere seront les projets de toute une vie, auraient ´et´e incroyablement plus difficiles `a mettre en œuvre.

Je tiens `a remercier en particulier Monsieur Favrel pour m’avoir accueilli au labora- toire PRISMa. Mes remerciements vont ´egalement `a Madame Dominique Rieu, Professeur au d´epartement informatique de l’IUT 2 rattach´e `a l’Universit´e Pierre Mend`es-France de Grenoble, Monsieur Herv´e Pingaud, Professeur `a l’Ecole des Mines d’Albi Carmaux, Mon- sieur Eric Rondeau, Professeur `a l’Universit´e Nancy 1, pour l’int´erˆet qu’ils ont port´e `a ce travail en acceptant de le rapporter.

Un grand merci `a Madame Matar, `a l’´equipe charg´ee de l’informatique au premier cycle de l’INSA ainsi qu’`a ses responsables, et enfin `a l’´equipe du CS Doua A¨ıkido, pour sa tol´erance, sa formidable ´energie et sa bonne humeur.

Merci `a toutes les personnes bienveillantes qui m’ont soutenues et aid´ees, explicitement ou non, dans mes recherches souvent difficiles, mais toujours passionnantes.

Les amateurs de musique ont ceci de p´enible qu’ils nous demandent toujours d’ˆetre totalement muets au moment mˆeme o`u nous souhaiterions ˆetre absolument sourds.

Oscar Wilde

A mes parents.

Table des mati` eres

Introduction g´en´erale xv

Partie I

Introduction 1

Chapitre 1

La mod´elisation de l’entreprise

1.1 D´efinitions et probl´ematique . . . 3

1.2 Concepts et composants de la mod´elisation d’entreprise . . . 6

1.3 Les m´ethodologies de mod´elisation d’entreprise . . . 7

1.3.1 Un exemple de d´emarche orient´ee ”d´ecisionnel” : GRAI . . . 7

1.3.2 GIM . . . 10

1.3.3 Un exemple de d´emarche orient´ee ”ressources humaines” : PERA 11 1.3.4 Exemples de d´emarche orient´ee ”syst`eme informatique” : IEM ou ARIS . . . 12

1.3.5 Vers un premier cadre int´egrateur : CIMOSA . . . 13

1.3.6 Vers une architecture f´ed´eratrice : GERAM . . . 16

1.3.7 Bilan sur les architectures d’int´egration : . . . 20

1.4 M´ethodes sp´ecifiques adapt´ees `a la conception et `a l’´evolution des SI : . 21 1.4.1 IDEF0 / SADT : . . . 21

1.4.2 Merise . . . 23

1.4.3 Approches objet . . . 25

1.4.4 M´ethodes orient´ees composants et patrons m´etiers . . . 26

1.4.5 RAD : . . . 27

1.4.6 Conclusion . . . 28

1.5 L’importance du workflow et du BPR dans la mod´elisation d’entreprise 29

1.5.1 Le workflow : . . . 29

1.5.2 Les process de business et leur r´eing´enierie . . . 32

1.6 Conclusion . . . 34

Chapitre 2 Administration des syst`emes distribu´es 2.1 Administration de base . . . 36

2.1.1 Configuration . . . 37

2.1.2 Gestion des pannes . . . 37

2.1.3 Performance . . . 38

2.1.4 Comptabilit´e . . . 42

2.1.5 S´ecurit´e . . . 43

2.2 Standards pour la s´ecurit´e des infrastructures . . . 43

2.2.1 La s´erie arc-en-ciel du DoD . . . 44

2.2.2 Le standard ITSEC de l’Union Europ´eenne . . . 45

2.2.3 Les ”Common Criteria” . . . 47

2.2.4 Le standard ISO 17799 . . . 51

2.3 M´ethodes de haut-niveau pour la s´ecurit´e des infrastructures . . . 56

2.3.1 Expressions des besoins et des objectifs de s´ecurit´e : m´ethode EBIOS . . . 56

2.3.2 La m´ethode MEHARI . . . 59

2.3.3 L’´etude des attaques : la m´ethode OCTAVE . . . 61

2.3.4 SNA . . . 63

2.3.5 La m´ethode Mass . . . 65

2.3.6 La mise en œuvre d’une architecture de s´ecurit´e et le suivi de son utilisation grˆace `a la m´ethode Safe . . . 66

2.4 Techniques de mise en œuvre de la s´ecurit´e au sein du syst`eme infor- matique . . . 70

2.4.1 La s´ecurit´e par le contrˆole d’acc`es . . . 70

2.4.2 La s´ecurit´e par le chiffrement . . . 71

2.4.3 Les logiciels et les protocoles de mise en œuvre des techniques de s´ecurit´e . . . 73

2.4.4 Conclusion . . . 76 2.5 M´ethodes avanc´ees de d´etection en mati`ere de s´ecurit´e des infrastructures 77

2.5.1 Propri´et´es attendues d’un SDI . . . 78

2.5.2 Les approches actuelles en d´etection d’intrusion . . . 78

2.5.3 Les approches empiriques . . . 81

2.5.4 La d´etection de l’inconnu : immunologie . . . 82

2.6 Vers l’administration proactive des syst`emes distribu´es . . . 83

Chapitre 3 Administration proactive `a l’aide d’agents mobiles 3.1 Pourquoi les agents mobiles ? . . . 86

3.2 Application aux syst`emes distribu´es . . . 87

3.3 S´ecurit´e et agents mobiles : . . . 90

3.3.1 Probl`emes courants . . . 90

3.3.2 Types d’attaques possibles sur un serveur : . . . 90

3.3.3 Points techniques . . . 91

3.3.4 De la s´ecurit´e des codes mobiles et de l’ex´ecution de fonctions encrypt´ees : . . . 93

3.3.5 Conclusion : . . . 94

3.4 Les principales plates-formes d’agents mobiles . . . 94

3.5 Conclusion . . . 97

Partie II 99

1.2 Etablissement des mod`eles statiques : concepts fondamentaux . . . 104

1.2.1 D´efinition du concept de ressource . . . 104

1.2.2 D´efinition du concept d’acteur . . . 105

1.2.3 D´efinition du concept de r`egle . . . 108

1.3 Mod`ele d’infrastructure et administration . . . 110

1.3.1 Mod`ele de donn´ees d’administration . . . 110

1.3.2 Mod`ele de donn´ees global de l’infrastructure . . . 113

1.4 La conception du mod`ele organisationnel . . . 113

1.4.1 Description des concepts : . . . 113

1.4.2 Le mod`ele organisationnel global : . . . 122

1.4.3 Lien entre le mod`ele organisationnel et le mod`ele d’infrastructure :124 1.5 Exploitation du mod`ele global et construction du mod`ele dynamique . 124 1.5.1 Vue g´en´erale : . . . 126

1.5.2 Phase descendante : . . . 127

1.5.3 Phase ascendante : . . . 129

1.6 Grille de description des ´echanges du syst`eme de gestion de qualit´e de service . . . 130

1.6.1 Organisation de la grille : . . . 130

1.6.2 Horizons strat´egique, tactique et op´erationnel : . . . 132

1.7 Utilisation de la signature de comportement . . . 138

1.8 Conclusion : . . . 140

Chapitre 2 Organisation g´en´erale du syst`eme de gestion crois´ee 2.1 Introduction . . . 141

2.2 Principe du syst`eme de gestion . . . 141

2.2.1 Un syst`eme de gestion multi-niveaux . . . 141

2.2.2 Des niveaux d´ecoup´es en zones d’administration . . . 142

2.3 Architecture d´etaill´ee du syst`eme de gestion . . . 145

2.4 Mise en œuvre du syst`eme de gestion de l’infrastructure via la plate- forme ”Aglets” . . . 145

2.5 Des serveurs et des agents : . . . 148

2.6 Gen`ese du syst`eme de gestion de l’infrastructure . . . 150

2.6.1 D´elimitation des zones d’administration . . . 151

2.6.2 Cr´eation des serveurs d’administration . . . 152

2.6.3 Collecte d’indicateurs `a l’aide des agents mobiles . . . 153

2.6.4 Le rˆole des contrats dans l’optimisation de crit`eres . . . 155

2.7 Implantation du syst`eme de gestion . . . 158

2.7.1 Rˆole des agents de collecte de donn´ees : . . . 158

2.7.2 Rˆole des agents d’administration : . . . 158

2.8 S´ecurit´e du syst`eme de gestion de l’infrastructure : . . . 159

2.8.1 Authentification des nœuds et acc`es au service aglets . . . 161

2.8.2 S´ecurisation de l’administration et de la collecte de donn´ees . . 162

2.8.3 S´ecurisation de la gestion des donn´ees inter-zone . . . 163

2.8.4 Possibilit´e d’itin´eraire ”inter-zone” pour un aglet . . . 164

2.9 Conclusion . . . 167

Chapitre 3 Mise en œuvre de la plate-forme et r´esultats 3.1 Introduction . . . 169

3.2 Validation du mod`ele de donn´ees du SI . . . 169

3.2.1 Rappel du contexte . . . 169

3.2.2 D´emarche . . . 170

3.2.3 Etude de cas sur une entreprise virtuelle . . . 171

3.2.4 Mise en place des agents mobiles de collecte d’information . . . 173

3.3 Aspects pratiques de la plate-forme et exp´erimentation . . . 175

3.3.1 M´ecanismes de s´ecurit´e mis en œuvre . . . 176

3.3.2 Sc´enarios concernant les agents mobiles de la plate-forme . . . . 177

3.3.3 Les agents mobiles : un syst`eme intrusif . . . 180

3.3.4 Simulation de pratiques collaboratives : injection de trafic . . . 184

3.4 Exemple : extraction des pratiques collaboratives . . . 184

3.4.1 Sc´enario de collecte adopt´e . . . 185

3.4.2 R´esultats . . . 187

3.5 Conclusion et perspectives . . . 188

Conclusion g´en´erale 189 Annexes Annexe A code A.1 Aglet 1, premi`ere classe : EnvoiParallele . . . 193

A.2 Aglet 1, seconde classe : Travailleur . . . 194

A.3 Aglet 2, premi`ere classe : Lanceur . . . 195

A.4 Aglet 2, seconde classe : Travailleur . . . 196

Annexe B

M´ecanismes avanc´es de s´ecurit´e : Kerberos

B.1 Kerberos et l’authentification - introduction . . . 199

B.2 Principe du tiers de confiance - le KDC . . . 200

B.3 L’authentification Kerberos . . . 201

B.3.1 Le service d’authentification (AS) . . . 201

B.3.2 Le service de d´elivrement de ticket (TGS) . . . 201

B.4 Limitations . . . 202

B.5 Un point sur l’authentification inter-domaine avec Kerberos : . . . 204

Annexe C Interop´erabilit´e des principales impl´ementations de Kerberos C.1 Contexte . . . 205

C.1.1 Microsoft et les ´ecarts par rapport aux standards . . . 205

C.1.2 Description des types d’interop´erabilit´e des impl´ementations . . 206

C.2 Tests . . . 207

C.2.1 Configuration avec un seul KDC . . . 207

C.2.2 Configuration avec plusieurs KDC . . . 208

C.2.3 Authentification avec un KDC sous UNIX . . . 210

C.2.4 Le service de changement de mots de passe . . . 211

Liste des acronymes 213

Bibliographie 217

Table des figures

1 Vue d’ensemble du syst`eme de gestion de la qualit´e de service dans le SI de

l’entreprise . . . xvii

2 La qualit´e de service de bout-en-bout dans le SI de l’entreprise . . . xvii

1.1 Cadre de r´ef´erence de mod´elisation des SI ([Lon04], page 36) . . . 4

1.2 S´equencement des ´etapes du cadre de r´ef´erence pour la conception et la mod´elisation du SI en vue de son ´evolution ([Lon04], page 38) . . . 5

1.3 Tableau des architectures de r´ef´erence GRAI . . . 8

1.4 La grille GRAI . . . 9

1.5 Un exemple complet de grille GRAI ([Lut96], page 45) . . . 10

1.6 L’architecture ARIS . . . 13

1.7 Cadre de mod´elisation CIMOSA . . . 14

1.8 Cycle de vie GERAM pour une entreprise ou une entit´e . . . 18

1.9 GERAM : Architecture et m´ethodologie de r´ef´erence pour l’entreprise . . . 19

1.10 Les diff´erents niveaux d’int´egration des syst`emes . . . 20

1.11 Les m´ethodes classiques de mod´elisation d’un SI . . . 21

1.12 L’activit´e dans IDEF0 . . . 22

1.13 Hi´erarchie de diagrammes IDEF0 . . . 23

1.14 Tableau r´ecapitulatif des types de workflow et des caract´eristiques associ´ees 32 2.1 Les diff´erents types d’administration des infrastructures . . . 36

2.2 Les concepts de la s´ecurit´e des syst`emes d’information . . . 44

2.3 Chronologie des standards . . . 45

2.4 Services de s´ecurit´e impliqu´es selon les diff´erents niveaux de certification (N=Non, Y=Oui, O=Optionel) . . . 46

2.5 Analyse de vuln´erabilit´e selon les diff´erents niveaux de certification d’apr`es [EEC91] (O = Oui) . . . 48

2.6 Comparaison des niveaux de certification ITSEC et TCSEC d’apr`es [EEC91] 49 2.7 Contexte d’´evaluation d´efini dans les Common Criteria d’apr`es [co98], p. 11 49 2.8 Mod`ele des concepts de s´ecurit´e d’apr`es [co98], p. 14 . . . 50

2.9 Niveaux de certifications des Common Criteria d’apr`es [co98] . . . 52

2.10 M´ethode propos´ee dans le standard ISO . . . 54

2.11 Notation de la probabilit´e de l’´ev´enement (P) . . . 54

2.12 Echelle de dommages (H) . . . 55

2.13 Evaluation des risques d’apr`es [Car01], p. 19 . . . 55

2.14 D´emarche EBIOS globale [DCS04] . . . 57

2.15 Les trois plans issus de la m´ethode . . . 61

2.16 Processus de gestion des risques avec OCTAVE [Ree03] . . . 62

2.17 Identification des risques et de leurs impacts [Ali04] . . . 63

2.18 Enchaˆınement des phases de SNA . . . 64

2.19 Risques et m´ethodes d’att´enuation associ´ees . . . 67

2.20 Les technologies utilis´ees par SAFE [CT00] . . . 68

2.21 Organisation d’une architecture s´ecuris´ee pour l’entreprise (selon SAFE) ([CT00] p.4) . . . 69

2.22 Les grandes ´etapes de l’authentification Kerberos . . . 75

2.23 Principe de base d’un firewall . . . 76

2.24 Sch´ema de la configuration g´en´erale d’un firewall . . . 77

3.1 Exemple de maillage . . . 89

3.2 Exemple de table de ph´eromones pour le nœud 1 . . . 89

3.3 Comparaison des diff´erentes plates-formes d’agents mobiles . . . 96

1.1 Constitution d’une Ressource . . . 104

1.2 Propri´et´e d’une Ressource . . . 105

1.3 R´ecursivit´e de la ressource d’infrastructure . . . 106

1.4 Historisation des donn´ees propres `a la ressource . . . 106

1.5 Interaction entre les processus issus d’une mˆeme tˆache . . . 107

1.6 Utilisation des r`egles par les processus . . . 108

1.7 Agencement des tˆaches, processus, acteurs et journaux . . . 109

1.8 Taux d’acc`es hebdomadaire sur un serveur web . . . 110

1.9 Exemple de perte de paquets sur des flux g´er´es `a l’aide de DiffServ . . . 111

1.10 Exemple de profils et de politiques pour le domaine OSI concernant la s´ecurit´e111 1.11 Lien entre la ressource, ses profils et ses politiques . . . 112

1.12 Agencement et ´echange de consignes entre acteurs . . . 114

1.13 Instanciation partielle du mod`ele . . . 115

1.14 Mod`ele global d’infrastructure . . . 116

1.15 Les acteurs et les rˆoles dans l’organisation . . . 117

1.16 Description de la macro-ressource . . . 118

1.17 Description des droits d’acc`es . . . 118

1.18 Description de la ressource organisationnelle . . . 120

1.19 La tˆache dans un workflow traditionnel . . . 121

1.20 La tˆache dans un workflow ad-hoc . . . 121

1.21 Les entit´es composant la partie workflow . . . 122

1.22 Mod`ele organisationnel global . . . 123

1.23 Corr´elation du mod`ele d’infrastructure et du mod`ele d’organisation . . . 125

1.24 Vue globale du syst`eme de gestion de la qualit´e de service du SI . . . 127

1.25 Vue macroscopique de la grille de description des interactions du syst`eme de gestion de la qualit´e de service . . . 128

1.26 Grille de description des interactions du syst`eme de gestion de la qualit´e de service . . . 131

1.27 Agencement et ´echange de consigne entre acteurs . . . 133

1.28 Illustration des ´echanges entre les acteurs `a travers les diff´erents niveaux de d´ecision . . . 136

1.29 D´etection de virus arrivant sur un serveur mail . . . 139

1.30 Moyenne des processus pr´esents dans la file d’ex´ecution d’un serveur de base de donn´ees sur les diff´erents jours de la semaine . . . 140

2.1 Une architecture multi-niveaux pour le syst`eme de gestion de mani`ere `a g´erer les trois niveaux du SI . . . 142

2.2 Une architecture multi-zone pour chaque niveau du syst`eme de gestion . . . 144

2.3 Architecture compl`ete du syst`eme de gestion . . . 144

2.4 Interactions entre les serveurs du syst`eme de gestion . . . 146

2.5 Architecture interne des serveurs de gestion de zone d’un niveau d´ecisionnel149 2.6 D´etail de la station d’administration . . . 150

2.7 L’infrastructure d’un niveau d´ecisionnel du SI comme un ensemble de nœuds151 2.8 L’infrastructure d’un niveau du SI segment´e en zones sp´ecifi´ees par des contraintes . . . 152

2.9 Les zones du SI sp´ecifi´ees en contraintes techniques . . . 153

2.10 Configuration initiale . . . 154

2.11 Collecte d’indicateurs . . . 155

2.12 Collecte sur les ´equipements pouvant recevoir les agents mobiles et les ´ equipements ne le pouvant pas . . . 156

2.13 Appel d’offre . . . 157

2.14 Soumission des offres . . . 157

2.15 choix des offres . . . 158

2.16 1. Initialisation d’un nouveau nœud : envoi des aglets en broadcast vers les autres nœuds . . . 159

2.17 2. Initialisation d’un nouveau nœud : extraction des informations contenues par les aglets par les nœuds destinataires . . . 159

2.18 3. Initialisation d’un nouveau nœud : envoi de nouveaux aglets contenant l’adresse du serveur vers le nouveau nœud . . . 160

2.19 Authentification et acc`es au service aglets . . . 161

2.20 Le service aglet et les cl´es de sessions des nœuds administrables . . . 162

2.21 Administration s´ecuris´ee des nœuds . . . 163

2.22 Collecte de donn´ees s´ecuris´ee . . . 164

2.23 Echanges de donn´ees horizontaux . . . 165

2.24 Echanges de donn´ees verticaux . . . 165

2.25 Partage des cl´es de cryptage entre les diff´erents niveaux pour l’authentifi- cation inter-domaine . . . 166

2.26 Authentification d’un serveur aupr`es d’un autre serveur (cas le plus d´efavorable) (les fl`eches montrent le trajet de la demande d’authentification) . . . 167

3.1 l’infrastructure de management d’une organisation virtuelle vue comme un ensemble de nœuds administrables (vue d’un seul niveau d´ecisionnel) . . . 170

3.2 Mod`ele global simplifi´e de l’organisation articul´ee autour des ressources,

des journaux de log, et des profils de comportement . . . 172

3.3 Infrastructure d’entreprise virtuelle simplifi´ee . . . 174

3.4 Plate-forme de mod´elisation de l’entreprise virtuelle . . . 174

3.5 Implantation du syst`eme de gestion de la qualit´e de service dans une en- treprise virtuelle . . . 176

3.6 La s´ecurit´e de la plate-forme . . . 177

3.7 Ex´ecution d’une commande `a distance sur une cible unique . . . 178

3.8 Ex´ecution d’une commande sur tout un itin´eraire . . . 179

3.9 Agents r´esidents sur les nœuds cibles. . . 180

3.10 Sc´enario choisi pour ´evaluer l’aspect intrusif du syst`eme de gestion de la qualit´e de service . . . 181

3.11 R´eception agent et ´emission agent + message sur mathieu05 (´echantillonnage ` a la minute) . . . 181

3.12 R´eception agent + ´emission message sur mathieu06 (´echantillonnage `a la minute) . . . 181

3.13 Octets re¸cus par mathieu02 et mathieu03 (´echantillonnage `a la minute) . . 182

3.14 Moyennes des octets en r´eception sur les diff´erents nœuds du r´eseau (´echantillonnage minute) . . . 182

3.15 Trafic erratique re¸cu sur mathieu02 ´echantillonn´e toute les une,cinq et 10 minutes . . . 183

3.16 Trafic en bloc re¸cu sur if04 ´echantillonn´e toute les une,cinq et 10 minutes . 183 3.17 Trafic en bloc re¸cu sur if04 ´echantillonn´e toute les 15 minutes (cas limite) 183 3.18 Trafic en bloc re¸cu sur if04 ´echantillonn´e toute les 20 minutes . . . 183

3.19 Configuration physique de la plate-forme . . . 185

3.20 S´equence des op´erations . . . 186

3.21 Flux de donn´ees . . . 186

3.22 Trafic erratique de type http sur mathieu02 (´echantillonnage `a la minute) . 188 3.23 Trafic de type ”transfert de fichiers” sur if04 (´echantillonnage `a la minute) 188 B.1 Authentification Kerberos . . . 203

C.1 Les diff´erentes configurations et les modes associ´es . . . 206

C.2 Relation de confiance bilat´erale entre KDC UNIX . . . 209

C.3 Relation de confiance unilat´erale . . . 209

C.4 Confiance bilat´erale entre KDC . . . 211

Introduction g´ en´ erale

Le contexte ´economique actuel est fortement ´evolutif, et pour r´epondre aux demandes du march´e, il est n´ecessaire que les entreprises soient suffisamment performantes, en ce sens qu’elles doivent ˆetre r´eactives et flexibles `a un environnement ´evoluant rapidement.

Pour cela, il est fondamental qu’elles poss`edent une organisation et une infrastructure de fonctionnement capable d’ˆetre reparam´etrable facilement pour prendre en compte ces

´

evolutions de mani`ere proactive, de telle mani`ere qu’elles soient en mesure de s’adapter

`

a l’´evolution du contexte ´economique. La qualit´e de l’adaptation de l’entreprise `a un contexte ´evolutif est fortement li´ee `a la qualit´e de service offerte par son infrastructure de fonctionnement. En effet, toute entreprise a besoin d’une telle infrastructure pour ˆetre op´erationnelle. Cette derni`ere prend en charge l’ensemble des op´erations de l’entreprise, et on l’appelle commun´ement le syst`eme informatique (SI). On peut associer au SI des indicateurs pour refl´eter la qualit´e de son fonctionnement, c’est la notion de qualit´e de service (QoS) de bout-en-bout. Dans ce cadre, l’infrastructure joue un rˆole important et doit correspondre aux besoins. Aussi, pour la dimensionner, il est n´ecessaire d’avoir une id´ee des besoins et il faut donc les d´efinir et les mod´eliser. Pour mener cette ´etude, nous recourons aux techniques de mod´elisation d’entreprise qui permettent d’obtenir des mod`eles donnant une vue statique compl`ete de l’entreprise et qui fournissent ainsi une base de pr´evisions permettant de r´ealiser le dimensionnement.

L’utilisation de l’infrastructure du SI peut ˆetre consid´er´ee comme ´etant dynamique et

´

evolutive, c’est-`a-dire qu’elle va elle-mˆeme g´en´erer de nouveaux besoins qui vont l’amener

`

a ´evoluer. Pour bien g´erer les ´evolutions, il est souhaitable d’utiliser les pr´evisions fournies par les mod`eles d’entreprise, et de les faire ´evoluer compte tenu du contexte dynamique dans lequel on se trouve. La notion de qualit´e de service est un outil permettant de fournir un feedback sur le bon fonctionnement de l’infrastructure et permet d’affiner les param´etrages et de pr´evoir les ´evolutions, ce qui aura un impact ´egalement sur les mod`eles d’entreprise, qui devront ˆetre mis `a jour `a leur tour. Ce positionnement est ´evident dans une entreprise conventionnelle mais il est renforc´e dans le cadre des entreprises virtuelles et/ou ´etendues car ces organisations n´ecessitent plus de flexibilit´e, de s´ecurit´e et de r´eactivit´e par rapport aux entreprises classiques, ce qui renforce les besoins en terme de bon fonctionnement de l’infrastructure. En outre, leur dur´ee de vie assez courte impose de concevoir une infrastructure adaptative qui ne soit pas un frein pour la collaboration inter-entreprise.

Pour prendre en compte l’´evolution des organisations, un processus de r´eing´enierie continu peut ˆetre envisag´e. Ce type de processus n´ecessite un syst`eme qui donne des in- formations pertinentes et relativement compl`etes sur l’utilisation r´eelle du SI. Ces donn´ees

d’administration sont issues de diff´erentes sources et ne sont pas structur´ees. Aussi, nous avons construit un mod`ele global permettant d’int´egrer les mod`eles de processus d’entre- prise, la description de l’infrastructure et les donn´ees d’administration refl´etant les process r´eels de l’entreprise, ce qui justifie une logique de reconstruction. Pour cela, nous propo- sons une d´emarche d’int´egration de ces diff´erentes vues. Cette approche nous conduit `a proposer un syst`eme de gestion de la QoS de bout-en-bout. En effet, la mise en place d’une bonne QoS d´epend d’une collecte de donn´ees d’administration repr´esentatives et de l’exploitation correcte de ces donn´ees. L’administration des infrastructures permet de collecter les donn´ees concernant les diff´erents processus th´eoriques et r´eels de l’entreprise, ce qui permet de garantir l’utilit´e du retour d’usage et d’adapter les mod`eles d’entreprise aux processus r´eels en supprimant en partie le temps de latence de la r´eing´enierie des processus.

On peut consid´erer l’optimisation de l’entreprise suivant deux axes :

♦ une approche de haut-niveau qui a pour but d’optimiser les processus `a partir des mod`eles d’entreprise

♦ une approche de bas niveau qui a pour but d’optimiser l’infrastructure de fonction- nement de l’entreprise

Les acteurs de ces approches n’´echangent traditionnellement pas d’informations car les mondes de la mod´elisation d’entreprise et de l’administration d’infrastructure sont cloisonn´es. Ce cloisonnement constitue un frein au bon d´eroulement de l’optimisation de l’entreprise. Or, ces deux approches sont compl´ementaires et il serait judicieux de cr´eer une synergie entre elles pour mettre en place des boucles de r´etroaction et ainsi am´eliorer l’optimisation de l’entreprise (figure 1).

Concr`etement, l’unification de l’administration des infrastructures avec la mod´elisation d’entreprise se traduit par le fait qu’on doit structurer des sources de donn´ees diff´erentes car le SI, qui constitue la mine d’information concernant `a la fois l’infrastructure et l’orga- nisation, n’est pas structur´e du point de vue de l’information qu’il contient. Pour parvenir

`

a cette structuration de l’information, il est n´ecessaire d’´etablir des mod`eles de donn´ees permettant de corr´eler les informations du SI entre elles. Pour obtenir un syst`eme int´egr´e, ces mod`eles devront ˆetre regroup´es au sein d’un mod`ele de donn´ees global unique, ce qui permettra de f´ed´erer la totalit´e des gisements d’information provenant du SI. Le mod`ele de donn´ees global permet de fournir une vue int´egratrice de l’ensemble de l’organisation, ce qui permet d’interpr´eter au mieux les donn´ees provenant du SI. On peut distinguer deux grandes classes de donn´ees dans le SI : les donn´ees relatives `a l’exploitation du SI (donn´ees op´erationnelles) et les donn´ees relatives au fonctionnement de l’organisation (donn´ees organisationnelles). Un mod`ele de donn´ees pour chacune de ces classes sera

´

etabli. Par ailleurs, outre la corr´elation, il faut ˆetre capable d’exploiter les informations du SI, ce dernier ´etant un syst`eme fortement distribu´e, dynamique, h´et´erog`ene et avec des contraintes de connectivit´e instable. Dans ce cadre, une approche centralis´ee de l’ex- ploitation des informations ne convient pas, et une approche distribu´ee de traitement de l’information, bas´ee sur des agents mobiles par exemple, semblerait plus adapt´ee.

La dimension organisationnelle du SI d´ecrit comment le syst`eme informatique, qui n’est autre qu’un ensemble de ressources mat´erielles et logicielles, est amen´e `a remplir un rˆole fondamental au sein de l’organisation (entreprise, universit´e...). Cela suppose que

Modèle d'entreprise Modèle réel entreprise

Workflow effectif Workflow

Flux prévisionnels ^données

traitements

Flux réels administration

proaction

explication

ordonnancement, tâches, acteurs

GAP

détection évolution permanente de l'entreprise

mine de données brutes indices de recherche de corrélation

récupère orientations théoriques

orientations réelles

profils d'utilisation de l'infrastructure profils d'utilisation de l'organisation

Fig. 1 – Vue d’ensemble du syst`eme de gestion de la qualit´e de service dans le SI de l’entreprise

Système d'information de l'entreprise

infrastructure technique : équipements de communication

infrastructure organisationnelle : processus de décision, échange entre services...

indicateurs techniques indicateurs organisationnels mise en correspondance

QoS de bout en bout proaction

Fig. 2 – La qualit´e de service de bout-en-bout dans le SI de l’entreprise

le syst`eme est con¸cu de telle mani`ere qu’il puisse prendre en compte la structure de l’organisation pour laquelle il op`ere. La dimension organisationnelle concerne donc tous les m´ecanismes mis en place au sein du SI pour que ce dernier puisse g´erer l’entreprise.

La dimension op´erationnelle du SI d´ecrit comment le SI fonctionne au sens technique du terme, c’est-`a-dire que cette dimension est charg´ee du contrˆole du bon fonctionnement des infrastructures de communication. Dans notre d´emarche de mise en place d’un syst`eme de gestion de la QoS de bout-en-bout, il sera fondamental de faire le lien entre la dimension infrastructurelle du SI et sa dimension organisationnelle. Ces concepts sont illustr´es par la figure 2. Le but des mod`eles de donn´ees ´etant de structurer les informations provenant du SI de mani`ere `a faire le lien entre les diff´erents niveaux strat´egiques du SI, ce qui est en fait une mise en perspective des donn´ees du niveau op´erationnel au niveau organisationnel, il sera n´ecessaire de faire une correspondance entre les mod`eles de donn´ees d’infrastructure et d’organisation. Une fois cette correspondance ´etablie, les donn´ees issues du niveau op´erationnel et celles provenant du niveau organisationnel s’expliqueront mutuellement.

Une fois que les mod`eles de donn´ees permettant la bonne exploitation des informations provenant des infrastructures sont ´etablis et mis en correspondance, il est n´ecessaire de mettre en place un syst`eme de collecte et d’exploitation des donn´ees adapt´e `a la complexit´e des infrastructures des SI distribu´es. Pour cela, le paradigme des agents mobiles nous a paru particuli`erement adapt´e par rapport aux approches centralis´ees classiques.

La mise en perspective et l’exploitation de donn´ees brutes dans un syst`eme distribu´e est un probl`eme classique qu’on retrouve tr`es souvent dans la gestion d’infrastructures in- formatiques. Il s’agit d’un probl`eme distribu´e, et un contrˆole centralis´e de la r´esolution de tels probl`emes est difficile, voire souvent impossible. La majorit´e des probl`emes trouvant leur origine au cœur des r´eseaux d’ordinateurs en font partie. Ces environnements sont tr`es souvent des assemblages d’´equipements h´et´erog`enes de taille et de complexit´e impor- tante dont la connectivit´e entre les ´el´ements est dynamique et incertaine. L’entretien et le contrˆole de telles infrastructures sont d’autant plus difficiles, car une approche centralis´ee, incompatible avec la distribution intrins`eque d’une telle infrastructure se r´ev`ele trop peu adaptative. Par ailleurs, la vuln´erabilit´e aux pannes de telles approches peut, `a l’extrˆeme, les rendre dangereuses. Beaucoup d’efforts sont actuellement d´eploy´es pour proposer des approches physiquement distribu´ees dans le domaine de contrˆole des r´eseaux, en par- ticulier dans les domaines de routage et de la protection des syst`emes. Ces approches pour la gestion de syst`emes distribu´es offrent des perspectives tout `a fait int´eressantes, c’est pourquoi nous nous proposons d’utiliser un syst`eme de gestion de qualit´e de service intrins`equement distribu´e, bas´e sur les technologies d’agents mobiles. Cette approche ap- pliqu´ee dans le contexte du syst`eme informatique de l’entreprise est `a la fois novatrice et prometteuse.

Cette th`ese est compos´ee de deux parties. La premi`ere partie d´ecrit les concepts li´es

`

a la mod´elisation d’entreprise pour ˆetre en mesure d’´etablir un mod`ele global de l’orga- nisation permettant de recouper les indicateurs provenant des diff´erents niveaux et de les mettre en perspective. Les concepts li´es `a l’administration des infrastructures informa- tique sont ensuite d´etaill´es de mani`ere `a fournir une connaissance de ce qui a ´et´e d´ej`a fait dans le domaine de l’administration des syst`emes d’information. L’administration des infrastructures informatiques et la mod´elisation d’entreprise sont des domaines vastes et tr`es diff´erents. Compte-tenu de la grande ´etendue des domaines que constituent la

mod´elisation d’entreprise et l’administration des infrastructures informatiques, l’´etat de l’art qui en est fait est plus large que pointu. Il a pour rˆole de donner les grandes lignes de ces domaines de telle mani`ere qu’il soit possible d’envisager ensuite leur int´egration dans le but d’optimiser l’organisation dans sa globalit´e. Par ailleurs, nous soulevons une mani`ere d’appr´ehender les m´ethodes de construction et de corr´elation des indicateurs entre-eux. Enfin, nous pr´esentons la technologie des codes mobiles, et les possibilit´es de s´ecurisation de tels codes. La seconde partie d´ecrit tout d’abord le mod`ele de donn´ees qui permettra de recouper les indicateurs provenant des diff´erents niveaux de l’organisation, puis nous pr´esenterons l’architecture du syst`eme de gestion de la qualit´e de service, avec une proposition de s´ecurisation de celui-ci, et enfin les r´esultats obtenus.

Premi` ere partie

Introduction

Face `a un contexte ´economique tr`es ´evolutif, il est n´ecessaire que les entreprises poss`edent une organisation optimale pour r´epondre `a des besoins parfois complexes qui changent rapidement. Un tel contexte a pouss´e les organisations `a former des alliances sous la forme d’entreprises virtuelles ou ´etendues qui sont des organisations devant ´evoluer rapi- dement pour r´epondre `a un besoin pr´ecis et volatile. Ces structures permettent d’am´eliorer la flexibilit´e, l’´evolutivit´e et la r´eactivit´e de l’organisation. Les groupements d’entreprise se cr´eent pour effectuer des projets sp´ecifiques limit´es dans le temps. Dans ce cadre, l’or- ganisation de l’entreprise et son infrastructure de fonctionnement doivent ˆetre optimis´ees au maximum. Dans un tel contexte, il y a n´ecessit´e d’int´egrer les diff´erents services, de partager les informations, de rationaliser l’organisation et d’´eviter les redondances, ce qui se r´esume `a une optimisation de l’organisation. Cette derni`ere peut ˆetre frein´ee, `a cause notamment de la diversit´e des communaut´es d’acteurs de l’organisation souvent cloisonn´ees et qui poss`edent diff´erents points de vue de l’entreprise et des am´eliorations

`

a apporter.

Par rapport au d´esir de faire ´evoluer l’entreprise, l’optimisation du syst`eme informa- tique (SI) pour mieux r´epondre aux besoins de l’entreprise est une n´ecessit´e, ce qui conduit

`

a une remise en question permanente du SI. Pour optimiser l’organisation de l’entreprise et la QoS de son syst`eme informatique, deux approches peuvent ˆetre envisag´ees :

♦ une approche de haut niveau qui consiste `a am´eliorer les processus de l’entreprise.

C’est une approche th´eorique dans laquelle il est n´ecessaire de mod´eliser l’entre- prise. Cette approche peut rencontrer le non-soutien des usagers car elle implique des changements abruptes de l’infrastructure. Elle pr´esente par ailleurs des d´elais d’ing´enierie important, ce qui peut cr´eer des d´ecalages entre les besoins exprim´es

`

a l’instant t, pour lesquels les processus ont ´et´e repens´es, et les besoins `a l’instant t+1, qui correspondent `a leur mise en œuvre r´eelle.

♦ une approche plus pragmatique consiste `a am´eliorer l’existant, c’est-`a-dire en am´elio- rant les infrastructures de fonctionnement de l’entreprise. Or l’administration du SI fournit toutes les cl´es pour cela, en terme d’informations et de moyens.

Pour ce mˆeme but d’optimisation, on a deux approches, l’une th´eorique et l’autre pra- tique. Ces deux approches travaillent sur des informations diff´erentes mais compl´ementaires pour l’optimisation. Or, ces informations ne sont traditionnellement pas corr´el´ees compte tenu du fait qu’elles appartiennent `a deux ”mondes” compl`etement dissoci´es. La mod´elisa- tion de l’entreprise appartient plus `a la cellule ”d´ecisionnelle” de l’entreprise tandis que l’administration est g´er´ee par des ´equipes d’exploitation informatique. Il est donc

n´ecessaire, par rapport `a l’int´erˆet de ces approches, de les explorer en d´etail. Nous nous int´eresserons donc dans un premier temps aux principes de base de la mod´elisation d’en- treprise, puis `a l’administration des infrastructures de fonctionnement, qui sont le plus souvent distribu´ees. Enfin, nous explorons l’int´erˆet de l’utilisation des agents mobiles pour une administration efficace et flexible des architectures distribu´ees. L’utilisation des technologies de pointe comme les agents mobiles pour effectuer l’administration des infra- structures de fonctionnement renforce le besoin d’avoir une s´ecurit´e optimale du syst`eme informatique, car ce type de technologie pousse `a utiliser de mani`ere extrˆeme tout le po- tentiel des ´equipements du syst`eme d’information, et peut introduire par l`a des failles de s´ecurit´e. Par ailleurs, le fait de travailler dans des environnements constitu´es d’entreprises virtuelles ou ´etendues renforce les besoins de partage et d’´echange de donn´ees, ce qui peut

´

egalement cr´eer des probl`emes de s´ecurit´e. Or, la sˆuret´e des syst`emes est capitale pour la survie de l’entreprise, il est donc n´ecessaire d’avoir `a disposition tout un arsenal de m´ethodes et de techniques permettant de concevoir une architecture du syst`eme informa- tique la plus sˆure possible. A cet effet, un panel de m´ethodes et de techniques permettant de r´epondre `a des contraintes de s´ecurit´e sera ´etudi´e.

1

La mod´ elisation de l’entreprise

1.1 D´ efinitions et probl´ ematique

La notion d’entreprise telle qu’elle est comprise dans le contexte de la mod´elisation d’entreprise peut se d´efinir comme l’ensemble organis´e des activit´es mises en œuvre par des ressources techniques et / ou humaines dans le cadre d’une finalit´e identifi´ee, qui est la raison d’ˆetre de l’organisation. L’entreprise dans sa globalit´e est un domaine tr`es vaste.

Dans le cadre de la productique, la mod´elisation d’entreprise concentre ses efforts sur le syst`eme de production, partie de l’entreprise correspondant aux activit´es de cr´eation de valeur. La mod´elisation d’entreprise a mis en ´evidence l’importance d’appr´ehender l’en- treprise `a travers ses fonctionnalit´es. Ce point de vue permet d’avoir une vision des ser- vices constituant l’entreprise. Le contexte ´economique, favorisant l’apparition d’alliances d’acteurs ´economiques au profit d’un projet collectif (entreprises virtuelles ou entreprises

´

etendues), met en avant la mod´elisation d’entreprise qui a dans ce contexte un rˆole majeur dans l’analyse des r´eseaux complexes constitu´es par les entreprises virtuelles ou ´etendues.

Aujourd’hui, la quasi-totalit´e des activit´es de l’entreprise, `a tous les niveaux, est g´er´ee par le syst`eme informatique de l’organisation (SI). Dans un tel contexte, mod´eliser l’orga- nisation se limite souvent `a mod´eliser son syst`eme informatique. La figure 1.1 repr´esente un cadre de r´ef´erence de mod´elisation et de conception des SI d’entreprise.

Selon le cadre de r´ef´erence (figure 1.1), le SI peut se d´ecomposer en 4 niveaux d’archi- tecture [Lon04] :

♦ niveau d’architecture m´etier. Il s’agit du niveau le plus abstrait et le plus proche de la strat´egie de l’organisation. Il doit r´epondre `a la question ”Quels sont les m´etiers de l’entreprise ?”. Une mani`ere de r´epondre `a cette question est de mod´eliser les processus de l’entreprise.

♦ niveau d’architecture fonctionnelle. Une fois que les m´etiers sont d´efinis, il faut r´epondre `a la question ”que va-t-on faire pour ˆetre capable de faire ces m´etiers ?”.

C’est le ”Quoi”. Il s’agit de l’´etape de sp´ecification du syst`eme informatique en terme d’applications.

♦ niveau d’architecture applicative. Il a pour rˆole de donner les cl´es permettant de r´ealiser les sp´ecifications d´efinies au niveau de l’architecture fonctionnelle. C’est le

”Comment”.

Les quatre niveaux du cadre de référence

Architecture métier

Architecture fonctionnelle

Architecture applicative

Architecture technique

Quels métiers ?

Quoi ?

Comment ?

Avec quoi ?

Acteurs et organisation stratégie de l'organisation

Niveau d'abstraction

Fig. 1.1 –Cadre de r´ef´erence de mod´elisation des SI ([Lon04], page 36)

♦ niveau d’architecture technique. Il s’agit du niveau le moins abstrait dans la hi´erarchie des niveaux d’architecture du SI. Il doit r´epondre `a la question ”Avec quels compo- sants va-t-on r´ealiser les applications d´efinies au niveau de l’architecture applicative.

C’est le ”Avec Quoi”.

Le s´equencement des ´etapes dans l’´elaboration de la politique de conception et d’´evolu- tion du SI est repr´esent´e par la figure 1.2. D’apr`es ce cadre de r´ef´erence, il est facile de comprendre l’importance de la mod´elisation des m´etiers de l’entreprise dans le but de mod´eliser le SI. En effet, ce sont les m´etiers de l’entreprise qui d´ecident du contenu du SI.

Or les m´etiers se d´ecrivent tr`es bien `a l’aide des processus cr´eateurs de valeur ajout´ee de l’entreprise. Dans ce cadre, on voit bien l’int´erˆet d’une mod´elisation orient´ee processus.

Un processus, au sens m´etier, manipule `a la fois des donn´ees statiques qui repr´esentent le ”cœur” du m´etier et des donn´ees dynamiques qui sont li´ees aux flux ´echang´es par le processus. Les donn´ees statiques ´evoluent peu et peuvent donc ˆetre parfaitement d´ecrites par un mod`ele de donn´ees. Les donn´ees dynamiques sont beaucoup plus volatiles, car elles sont li´ees aux flux, et les flux ´evoluent rapidement dans le contexte dynamique de l’entreprise. C’est ici o`u ce qu’on appelle le workflow (”science de la gestion des flux”) prend toute son importance. Si le mod`ele des donn´ees ”m´etiers” est ´etabli, ce qui est envisageable avec une bonne expertise relative aux m´etiers de l’entreprise, la mod´elisation des processus peut se ramener `a la mod´elisation des flux (workflow).

Il existe diff´erentes formes de flux dans l’entreprise. Les plus ´evidents sont les flux pro- duits, et les flux financiers. Mais il existe un d’autres types de flux pr´epond´erants : les flux d’informations et de d´ecision. Ces derniers sont d’autant plus complexes que l’entreprise

1.1. D´efinitions et probl´ematique

Niveaux du cadre de référence

Métier

Fonctionnel

Applicatif

Technique

Stratégie métier

Architecture métier existante

Architecture métier cible

Architecture fonctionnelle cible

Architecture applicative cible

Architecture technique cible Architecture

applicative existante

Architecture technique existante

Fig. 1.2 – S´equencement des ´etapes du cadre de r´ef´erence pour la conception et la mod´elisation du SI en vue de son ´evolution ([Lon04], page 38)

mod´elis´ee l’est. Les activit´es concernant l’information (traitement, m´emorisation, trans- port) doivent ˆetre coh´erentes avec les autres activit´es de l’entreprise. Cette coh´erence est d´efinie d’un point de vue s´emantique (la bonne information) et d’un point de vue dyna- mique (au bon moment). Dans ce cadre, il est fondamental de maˆıtriser les flux (maˆıtrise du workflow) pour mod´eliser l’entreprise.

La conception, l’´evaluation, l’exploitation et l’´evolution des syst`emes d’information font partie des th`emes majeurs de la productique, et, `a ce titre, concernent la mod´elisation d’entreprise. L’´evaluation des syst`emes d’information vise `a connaˆıtre les performances de ce dernier. Elle est utilis´ee en g´en´eral pour comparer les performances existantes `a des per- formances attendues. La conception d’un syst`eme informatique va utiliser la mod´elisation d’entreprise comme outil de sp´ecification. L’´evolution permanente du contexte ´economique conduit `a envisager en permanence de nouvelles organisations. Il existe donc un besoin d’adaptation permanent. On peut noter que mˆeme dans le cas d’un syst`eme compl`etement nouveau, une action de conception ne partira jamais de rien. Il est beaucoup plus courant de faire ´evoluer les installations existantes que d’en cr´eer de nouvelles. Les entreprises actuelles sont beaucoup plus souvent demandeuses d’actions de restructuration que d’ac- tions de conception. La liaison avec le niveau strat´egique apparaˆıt aujourd’hui comme

´

etant indispensable dans la course `a la performance. Ainsi, le d´ecouplage entre la gestion des infrastructures et la gestion de l’organisation doit ˆetre proscrit : les fonctionnalit´es et les performances du syst`eme de production doivent ˆetre d´efinis en harmonie avec la strat´egie de l’entreprise.

1.2 Concepts et composants de la mod´ elisation d’en- treprise

Un mod`ele est une abstraction et une repr´esentation simplifi´ee de la r´ealit´e. Elle agit comme un filtre sur la partie du monde r´eel qu’elle repr´esente, ne conservant que l’infor- mation essentielle pour l’´etude et supprimant les d´etails inutiles. La d´emarche g´en´erale consiste `a abstraire les relations entre les entit´es mod´elis´ees. Ce processus d’abstraction est appel´e mod´elisation. Nous faisons la distinction entre la mod´elisation et le formalisme utilis´e pour effectuer le mod`ele. La mod´elisation est une repr´esentation abstraite du monde r´eel, tandis que le formalisme de mod´elisation est utilis´e pour d´ecrire cette repr´esentation.

Les mod`eles d’entreprise doivent permettre :

♦ la repr´esentation du syst`eme, tant son ´etat actuel que les diff´erentes possibilit´es d’´evolution,

♦ l’´evaluation (du syst`eme existant ou `a venir),

♦ l’optimisation des performances du syst`eme.

En plus de ces besoins techniques, les mod`eles doivent remplir un rˆole de support aux acteurs humains du projet en favorisant :

♦ la communication `a l’int´erieur du projet,

♦ la communication dans l’espace (´echanges entre les acteurs pouvant appartenir `a des structures diff´erentes de comp´etences diff´erentes),

♦ la communication dans le temps (archivage et documentation),

♦ les d´ecisions de conception ou de modification du syst`eme.

La mod´elisation d’entreprise doit donc proposer des formalismes conduisant `a des mod`eles permettant la valorisation du syst`eme, et d’autre part, les mod`eles obtenus doivent ˆetre facilement appr´ehendables par les acteurs de l’entreprise. De plus, par rapport

`

a la complexit´e de l’entreprise, les mod`eles doivent pouvoir ˆetre d´eclin´es suivant plusieurs points de vue (projection) et adopter diff´erents niveaux de d´etail pour correspondre aux besoins de leurs utilisateurs se situant `a tous les niveaux de l’entreprise. Les outils pro- pos´es par la Mod´elisation d’Entreprise sont constitu´es de mod`eles, de m´ethodes, et de d´emarches de raisonnement ainsi que de supports informatique assistant le concepteur dans sa tˆache d’am´elioration. L’ensemble des m´ethodes manipule les concepts principaux suivant :

♦ l’activit´e,

♦ le processus,

♦ l’´ev´enement,

♦ la ressource,

♦ le flux.

Pour r´ealiser un mod`ele, il est n´ecessaire d’adopter une d´emarche structur´ee, ceci afin d’obtenir un r´esultat utilisable. C’est l’int´erˆet des m´ethodes. Une m´ethode peut avoir

1.3. Les m´ethodologies de mod´elisation d’entreprise des bases th´eoriques formelles. En r`egle g´en´erale, une m´ethode ´evolue au cours de son

´

elaboration et de son utilisation. Elle d´efinit par ses r`egles un mode d’emploi qui permet de r´esoudre un probl`eme. La repr´esentation d’un probl`eme peut ˆetre r´ealis´ee au travers d’un mod`ele, construit dans un certain formalisme. On distingue la notion de m´ethode de la notion de m´ethodologie. Nous consid´erons une m´ethodologie comme un ensemble de m´ethodes utilisant des formalismes de mod´elisation et des outils de repr´esentation as- soci´es (graphiques ou textuels), des mod`eles de r´ef´erence et une approche structur´ee. Une m´ethode permet de r´esoudre un probl`eme ´el´ementaire isol´e tandis qu’une m´ethodologie organisant un ensemble de m´ethodes permet de r´esoudre un probl`eme plus global. SADT, IDEFx, GRAI sont des m´ethodes, tandis que IDEF (l’ensemble des IDEFx), GIM, CI- MOSA sont des m´ethodologies. Une m´ethodologie est en g´en´eral d´evelopp´ee en conjonc- tion avec une architecture de r´ef´erence. Une architecture de r´ef´erence fournit un canevas d´ecrivant les diff´erents formalismes `a utiliser pour mener `a bien l’´etude tandis que la m´ethodologie d´ecrit comment les utiliser. Une architecture de r´ef´erence est donc un en- semble structur´e de m´eta-mod`eles repr´esentant les invariants du syst`eme `a mod´eliser.

CIMOSA, ARIS, PERA et GERAM ont propos´e diff´erentes architectures de r´ef´erence.

1.3 Les m´ ethodologies de mod´ elisation d’entreprise

La mod´elisation d’entreprise a pour but de d´evelopper et de promouvoir des m´ethodes, des techniques, des mod`eles et des outils permettant de maˆıtriser le comportement de l’en- treprise dans le temps. La mod´elisation d’entreprise est une approche de type ”top/down”, en ce sens qu’on part des aspects g´en´eraux avant de les raffiner pour obtenir des mod`eles sp´ecifiques pouvant ˆetre impl´ement´es. Durant la mod´elisation, l’accent peut ˆetre mis sur diff´erentes facettes, ce qui a donn´e diff´erentes d´emarches de mod´elisation possibles. Par exemple, on peut orienter la mod´elisation suivant le syst`eme d´ecisionnel, ou bien suivant les ressources humaines, ou encore en partant du syst`eme informatique.

1.3.1 Un exemple de d´ emarche orient´ ee ”d´ ecisionnel” : GRAI

Le mod`ele GRAI [DBP83] [Rob91] donne une description g´en´erique d’un syst`eme ma- nufacturier en se focalisant sur les d´etails de la partie de contrˆole du syst`eme. Dans sa m´ethodologie, l’importance de l’initialisation du programme bas´e sur le syst`eme courant est reconnu. Dans son framework de mod´elisation, les utilisateurs sont autoris´es `a propo- ser des imp´eratifs pour le nouveau syst`eme. Un ensemble d’outils de mod´elisation ont ´et´e d´evelopp´es et pr´esent´es pour promouvoir la facilit´e de compr´ehension pour des utilisateurs qui ne sont pas forc´ement des informaticiens. Le tableau 1.3 montre les diff´erentes archi- tectures de r´ef´erence du mod`ele GRAI et `a quels niveaux de d´ecision ces architectures appartiennent.

Le Syst`eme de D´ecision est d´ecompos´e en Niveaux de D´ecision et Centres de D´ecision.

Chaque Niveau de D´ecision est caract´eris´e par un horizon et une p´eriode, crit`eres de d´ecomposition li´es aux caract´eristiques temporelles des d´ecisions. L’horizon correspond

`

a la dur´ee de la port´ee de la d´ecision. La p´eriode correspond `a l’intervalle de temps au bout duquel il est n´ecessaire de remettre en cause les d´ecisions ´elabor´ees sur l’horizon

Type

de flux Données Process Opérations Niveau

de décision Conceptuel

Organisationnel

Physique

Modèle conceptuel de données Modèle de données d'organisation Modèle de données physique

Modèle conceptuel de process Modèle de process d'organisation Modèle de process physique

Modèle conceptuel d'opérations

Modèle opérationnel d'organisation Modèle opérationnel physique

Fig. 1.3 – Tableau des architectures de r´ef´erence GRAI

consid´er´e. Chaque Niveau de D´ecision est d´ecompos´e en activit´es. Les activit´es d’un mˆeme niveau de d´ecision sont regroup´ees selon leurs objectifs. On appelle Centre de D´ecision un ensemble d’activit´es ayant mˆeme horizon et p´eriode, devant ˆetre ex´ecut´es suivant les mˆemes objectifs donn´es par un seul cadre de d´ecision.

Un Centre de D´ecision est compos´e :

♦ d’activit´es de d´ecision et d’ex´ecution,

♦ de relations d’entr´ee (coordination, d´ecomposition, synchronisation),

♦ de relations de sortie (r´esultat des d´ecisions prises, cadre de d´ecision, synchronisa- tion, suivi),

♦ de relations internes au centre de d´ecision entre les diff´erentes activit´es qui le consti- tuent.

Les diff´erents Centres de D´ecision sont reli´es entre eux aux travers de liens de d´ecision et d’information. La notion deCadre de D´ecision correspond `a un lien de type d´ecisionnel entre deux Centres de D´ecision. Les deux Centres de D´ecision consid´er´es n’appartiennent pas forc´ement au mˆeme niveau de d´ecision. Le cadre de d´ecision transmet les informations n´ecessaires `a la prise de d´ecision du centre de d´ecision r´ecepteur, `a savoir les objectifs, les crit`eres et les proc´edures `a prendre en compte lors des prises de d´ecision. Lesliens de type informationnel mod´elisent les flux d’information entre deux Centres de D´ecision, entre un Centre de D´ecision et l’environnement ext´erieur de l’entreprise consid´er´ee, ou encore entre un Centre de D´ecision et le syst`eme physique. Les relations entre les Centres de D´ecision sont mod´elis´ees au travers de laGrille GRAI. Cette derni`ere repr´esente une vision globale et macroscopique de la structure du syst`eme ´etudi´e. Elle identifie et positionne les diff´erents centres de d´ecision les uns par rapport aux autres. Elle permet de mettre en

´

evidence les principaux liens d´ecisionnels ou cadres de d´ecision de l’organisation ´etudi´ee.

La grille GRAI (figure 1.4) permet de d´ecomposer le syst`eme mod´elis´e selon les crit`eres d´efinis par la m´ethode GRAI :

♦ les couples horizon-p´eriode relatifs `a une prise de d´ecision sont repr´esent´es sur l’axe vertical,

1.3. Les m´ethodologies de mod´elisation d’entreprise

Fonctions

Informations Externes

Gérer les produits Planifier la production

Gérer les ressources Informations Internes Humaines Techno.

Acheter Approv.

Centre de décision H/P

H = P =

H = P =

H = P =

H = P =

Fig. 1.4 – La grille GRAI

♦ les activit´es d´ecisionnelles, group´ees par fonctionnalit´es, sont repr´esent´ees sur l’axe horizontal.

L’intersection entre une fonction et un niveau de d´ecision horizon/p´eriode (H/P) repr´esente un centre de d´ecision. Les liens de type informationnel sont repr´esent´es par une fl`eche `a pointe simple, tandis que les Cadres de D´ecision sont repr´esent´es par une fl`eche `a double-pointe allant du Centre de D´ecision ´emetteur vers le Centre de D´ecision r´ecepteur. La colonne ”Informations Externes” repr´esente l’interfa¸cage du Syst`eme de Gestion de Production avec le monde ext´erieur de l’entreprise. La colonne ”Informations Internes” correspond `a l’interfa¸cage du Syst`eme de Gestion de Production avec le Syst`eme Physique. Les informations repr´esent´ees dans ces deux colonnes sont class´ees en fonction des horizons et p´eriodes qui les caract´erisent. Les colonnes entre ”Information Externes”

et ”Information Internes” repr´esentent les fonctions g´en´eriques du syst`eme analys´e.

L’´elaboration d’une Grille GRAI est r´ealis´ee selon les ´etapes suivantes :

♦ identification des fonctions de gestion de production de l’entreprise ´etudi´ee. Parmi toutes les fonctions possibles, ne sont repr´esent´ees dans la grille que les fonctions pr´esentes dans l’entreprise,

♦ identification des couples horizon-p´eriode correspondant `a chaque fonction. A la fin de cette op´eration, la structure de la Grille GRAI est constitu´ee,

♦ positionnement des Centres de D´ecision aux intersections des fonctions et des couples (horizon, p´eriode),

♦ ´etablissement des liens d’information et de d´ecision entre les Centres de D´ecision.

Fonctions

Informations Externes

Gérer les produits Planifier la

production Gérer les ressources Informations Internes Acheter Approv.

H/P

H = 2 ans P = 1 mois H = 8 mois P = 1 mois H = 6 mois P = 1 sem.

H = 3 mois P = 1 jour

H = 1 jour P = Temps réel

Prévisions ventes Carnet commandes

Enregistrer commandes

Recherche fournisseurs

Envoyer commandes

Relancer Définir politique appro.

critiques Définir para.

appro.

Faire plan appro.

Enregistrer

E/S Lancer Fabriquer

Gérer le personnel Définir S/T conjoncturelle Définir politique d'embauche et S/T structurelle

Définir S/T conjoncturelle

Niveau des stocks Faire Plan

long terme

Faire PDP

Faire Ordo.

moyen terme Faire Ordo.

court terme MRP

Fig. 1.5 – Un exemple complet de grille GRAI ([Lut96], page 45) La figure 1.5 repr´esente une grille GRAI achev´ee.

La m´ethode GRAI fournit des outils graphiques pour mod´eliser le syst`eme de d´ecision d’une entreprise, notamment la fa¸con dont les d´ecisions sont prises et les responsabilit´es r´eparties. Pour arriver `a cela, la m´ethode GRAI fait intervenir les diff´erents acteurs dans les grilles, notamment les flux d’information, les ressources de l’entreprise, les proces- sus (activit´es). Toutefois la m´ethode GRAI ne supporte pas la mod´elisation des aspects fonctionnels, informationnels et physiques cit´es pr´ec´edemment. Elle se contente d’y faire r´ef´erence pour appuyer la mod´elisation du syst`eme de d´ecision. La m´ethode GRAI ne couvre qu’un aspect restreint de l’entreprise. Afin d’´elargir son champ d’action, des tra- vaux ont ´et´e entrepris au laboratoire GRAI afin de supporter les aspects de mod´elisation fonctionnelle et informationnelle en int´egrant les m´ethodes IDEF0 et MERISE au proces- sus de mod´elisation GRAI. Les r´esultats de ce travail ont donn´e naissance `a la m´ethode GRAI-IDEF0-MERISE ou GIM.

1.3.2 GIM

GIM [RZP89] est une m´ethodologie d´evelopp´ee au laboratoire GRAI de l’Universit´e de Bordeaux en 1988 afin de rem´edier `a certaines lacunes de la m´ethode GRAI et notam- ment ´etendre le champ de la mod´elisation au Syst`eme de Production et non plus seule- ment au Syst`eme de D´ecision. GIM mod´elise donc les trois sous-syst`emes du Syst`eme de Production : sous-syst`eme d´ecisionnel, informationnel et physique. GIM est l’acro- nyme de GRAI-IDEF0-Merise. En effet, GIM r´esulte du constat de la compl´ementarit´e des m´ethodes GRAI, IDEF0 et Merise pour l’analyse et la conception des syst`emes de

1.3. Les m´ethodologies de mod´elisation d’entreprise production et se veut une m´ethodologie int´egrant ces trois m´ethodes. GIM distingue trois aspects diff´erents : les traitements, les donn´ees et les op´erations. Ces trois aspects sont mod´elis´es `a trois niveaux d’abstraction diff´erents :

♦ le niveau conceptuel,

♦ le niveau op´erationnel,

♦ le niveau physique.

Plus compl`ete que la m´ethode GRAI, la m´ethodologie GIM pr´esente toutefois un certain nombre de lacunes. Nous citerons notamment :

♦ la mod´elisation de syst`eme physique est incompl`ete. Il est fait de r´ef´erences aux res- sources physiques utilis´ees au travers des m´ecanismes des boˆıtes IDEF0. Toutefois, il n’existe pas de mod`ele physique, ou mˆeme logique, de ressources dans GIM.

♦ l’int´egration des mod`eles est faible. En effet, l’int´egration de GRAI, IDEF0 et Me- rise dans GIM est r´ealis´ee `a travers des r`egles de coh´erence entre les mod`eles : les diff´erents mod`eles doivent ˆetre r´ealis´es ind´ependamment les uns des autres. ll n’y a pas unification des concepts de GRAI, IDEF0 et Merise utilis´es pour mod´eliser chacun des aspects du Syst`eme de Production en un formalisme unique. Ceci pose notamment des probl`emes lors de la validation des diff´erents mod`eles deux `a deux.

Il n’est pas prouv´e que les r`egles de coh´erence soient transitives.

♦ une fois les mod`eles organisationnels r´ealis´es, GIM a recours `a des techniques conven- tionnelles pour assurer le d´eveloppement au niveau physique. La couverture r´eelle de GIM se limite donc actuellement aux niveaux conceptuels et op´erationnels.

1.3.3 Un exemple de d´ emarche orient´ ee ”ressources humaines” : PERA

L’architecture PERA [Wil94] est issue des travaux du Consortium Industrie-Universit´e auPurdue Laboratory for Applied Industrial Control aux USA. Elle comprend une archi- tecture de r´ef´erence et une m´ethodologie associ´ee. L’architecture est compos´ee de sept couches successives. Des phases m´ethodologiques couvrent le d´eveloppement du syst`eme

`

a travers les couches.

♦ La couche identification : sert `a identifier l’entit´e de l’entreprise `a mod´eliser (com- plexe industriel, atelier...).

♦ La couche concept : `a ce niveau, l’entit´e `a mod´eliser permet la description des missions, des processus de gestion, des fournisseurs, etc... qui sont `a la base de la d´efinition des besoins.

♦ La couche d´efinition : permet la d´efinition de deux types de besoins, les besoins de gestion (gestion de la production, des informations...) et les besoins de production (op´erations de fabrication). Ces besoins sont ensuite collect´es dans des modules ou des fonctions, puis structur´es en r´eseaux pour exprimer les flots d’informations, de mati`eres et d’´energie.

♦ La couche de sp´ecification : sp´ecifie les architectures d’information et de fabrication et introduit le facteur humain, en pr´ecisant les comp´etences `a attacher pour chaque tˆache, ce qui d´efinit l’architecture humaine et organisationnelle.

♦ La couche de conception d´etaill´ee : les architectures fonctionnelles pr´ec´edentes sont traduites en architectures d’implantation en pr´ecisant les technologies `a utiliser pour effectuer les tˆaches sp´ecifi´ees.

♦ La couche d’implantation : les ´equipements physiques, les ´equipes, etc... sont mis en place.

♦ La couche de mise en œuvre et de maintenance.

PERA et la m´ethodologie associ´ee sont des moyens informels qui conduisent les uti- lisateurs durant un projet d’int´egration d’entreprise. Ceci `a l’avantage de faciliter la compr´ehension et l’utilisation grˆace `a sa repr´esentation graphique et sa m´ethodologie compl`ete. Les aspects humains sont correctement pris en compte. De plus, PERA a montr´e son extensibilit´e afin de couvrir tout type d’industrie. Les limites de cette approche infor- melle r´esident dans le manque de formalisme math´ematique et de mod`eles implantables, ce qui oblige de tout remod´eliser `a chaque fois `a l’aide de m´ethodes plus sp´ecifiques.

1.3.4 Exemples de d´ emarche orient´ ee ”syst` eme informatique” : IEM ou ARIS

L’importance de la maˆıtrise des processus au sein du SI a ´et´e soulign´ee dans la sec- tion 1.1. En effet, comme les processus sont tr`es corr´el´es aux objectifs strat´egiques de l’organisation, il existe une r´eelle n´ecessit´e de pouvoir les contrˆoler, et donc d’ˆetre en mesure de traiter les donn´ees li´ees aux processus. IEM (Integrated Information Model- ling for Computer Integrated Manufacturing (CIM)) [SMS90] [MSJ91] offre un cadre de mod´elisation orient´e donn´ees en vue de cr´eer un syst`eme de production int´egr´e. IEM est une approche de mod´elisation du syst`eme int´egr´e d’information, qui permet de d´eriver diff´erents mod`eles d’entreprise `a partir d’un noyau. Le noyau est un ensemble d’objets g´en´eriques issus de trois classes : produits, ordres et ressources. Chaque objet d´efini dans une entreprise manufacturi`ere doit appartenir `a l’une de ces classes. Les classes ”pro- duit” et ”ressource” peuvent contenir des mati`eres, de l’information ou de l’´energie. La classe des ordres ne contient que des informations. Les activit´es du syst`eme de production consid´er´e traitent et modifient les objets ainsi d´efinis, ils repr´esentent leurs m´ethodes. La structure objet initiale est enrichie au fur et `a mesure en rajoutant au mod`ele de l’en- treprise (objets avec leurs m´ethodes) des couches pour repr´esenter la solution technique, en adaptant le mod`ele g´en´erique `a un environnement particulier (applications propres au syst`eme, stockage des donn´ees, r´eseaux...). D’autres ´el´ements relatifs `a l’organisation et aux responsabilit´es des diff´erents membres du personnel peuvent ˆetre rajout´es aux objets de l’entreprise. L’inconv´enient majeur de cette m´ethode est le d´efaut d’encapsulation du syst`eme avec ses activit´es, principe important de l’approche objet.

ARIS (Architecture of Integrated Information Systems) [She93] [SGK95] est `a la fois un cadre de mod´elisation g´en´erique et un outil de mod´elisation des processus d’entreprise.

Le cadre de mod´elisation ARIS (figure 1.6), est bˆati sur une approche multi-niveaux et