TH4211 PDF

‫الجمه ـ ــورية الجزائريـ ـة الديمقراطي ـ ـة الشعبي ـ ـة‬
République Algérienne Démocratique et Populaire

‫وزارة التعليـ ـ ـم الع ـ ـ ـ ـال ـ ـ ـي والبح ـث العلمـ ـ ـ ـ ـ ـ ـي‬
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
‫كلي ـ ـة العـ ـلـ ـ ـوم الدقيقة والتطبيقية‬

Faculté des Sciences ‫ آ‬Exactes et Appliquées
‫قس ـم اإلع ـالم ال ل ـ ـ ـي‬
Département Informatique
MÉMOIRE
Présenté pour l’obtention du Diplôme de Magister
Spécialité : Informatique
Option : Ingénierie des Données et des Connaissances
Par : Mr. MENAD Si Mohamed Bekkai
Titre
CONCEPTION D’UN PROCESSUS DE

DEVELOPPEMENT PAR UML – WORKFLOW:
ACTIVITÉS BUDGETAIRES (AVAL/Sonatrach)
11 / ……..…
Soutenu le ……..… 03 / ……………
2014 devant la commission de jury :
Mr. RAHMOUNI Mustapha Kamel, Professeur à l’Université d’Oran Président

Mr. Abdi Mustapha Kamel, Maître de Conférences à l’Université d’Oran Examinateur
Mr. Atmani Baghdad, Maître de Conférences à l’Université d’Oran Examinateur
Mme Nait Bahloul Safia, Maître de Conférences à l’Université d’Oran Encadreur

Mr. Draou Abbes, Chef de Département-Etude et Développement–AVAL/Sonatrach- Invité
Remerciements
Je tiens tout d’abord à remercier Madame Nait Bahloul Safia, maître de

conférence (MCA) à l'université d’Oran, de m'avoir guidé, soutenu, aidé, conseillé et
encouragé au cours de ce projet. Qu'elle trouve ici, l'expression de ma sincère
reconnaissance et considération.
Je tiens aussi à remercier :
- Monsieur Rahmouni Mustapha Kamel, Professeur à l'université d’Oran de m’avoir

fait l’honneur d’accepter de présider le jury de ma soutenance.
- Messieurs Atmani Baghdad et Abdi Mustapha Kamel, maîtres de conférence à
l'université d’Oran pour l’honneur qu’ils m’ont fait de juger ce travail.
- Monsieur Draou Abbes, chef de département études développement et intégration
au niveau de l’activité AVAL/Sonatrach – oran, d’avoir accepté de faire partie de ce
jury en tant qu’invité.
Je remercie également tout le personnel d’encadrement pédagogique et

administratif de département informatique de la faculté des sciences de l’université
d’Oran, et en particulier le chef de département Mr. le docteur Bouamrane K., Mme
Meziane Hassina. Maître de conférence à l’université d’Oran, Mlle. Benabbou Amel
Maître assistant à l’université de Mostaganem, Mr. Benaribi Fethi Imad, maître
assistant à l’université de Ain Témouchent et Mme. Benouadah Mokhtaria pour
leurs aides, conseils et encouragements.
Je remercie aussi tout le personnel du service des traitements au niveau de la

direction de l’éducation de Mostaganem, et en particulier le chef de service Mr. Si Afif
Med Benali pour le soutien qui m’a accordé au long de ce projet, le chef de bureau
Mr.Saadoun Habib pour son aide et mes collègues de bureau des professeurs
d’enseignement secondaire.
Je n'omettrais pas de remercier vivement tout le personnel de département

études développement et intégration au niveau de l’activité AVAL/Sonatrach – Oran,
avec lesquels j'ai pu échanger des idées, discuter, partager et vivre des moments
agréables parmi eux.
Enfin, un grand et chaleureux merci à ma femme pour sa patience et son

soutien moral pendant toutes ces années de travail.
Je dédie ce modeste travail à :
Mes défunts parents,

Ma femme et ma petite étoile Amira-Dehiba,
Mes beaux parents,
Mes défunts frères et sœurs,
Mes frères et mes sœurs,
Mes familles Menad, Bernou, Djordem, Mortet et Tekkouk ,
Mes neveux et surtout Touati et Abdellah Benkhatab.
Résumé i
Résumé : Le budget est un processus lourd et complexe à mettre en œuvre. Le

premier rôle du budget est de donner un cadre pour l’exercice à venir. La gestion
budgétaire est un mode de gestion qui englobe tous les aspects de l'activité de
l'organisation qui comprend une période de budgétisation (construction de l'ensemble
cohérents de prévisions chiffrées) puis une période de contrôle budgétaire. Les
prévisions budgétaires et leur planification au cours de toute l’année est une des parties
essentielles dans la gestion d’une entreprise industrielle. Elle permet aussi de donner
des délais courts aux demandes/commandes des clients et des agents de l’entreprise.
La gestion et le contrôle budgétaire au niveau de l’activité Sonatrach/AVAL n’adopte
pas de technique et de méthode automatique suffisante à la solution du processus
budgétaire. Les difficultés à ce niveau peuvent être vues classées en deux catégories :
des problèmes de gestion et des problèmes de contrôle. Le projet de l’automatisation de
la gestion et du contrôle budgétaire devient donc une nécessité prioritaire.
Notre objectif dans ce projet est la mise en place d'une solution informatique au
problème de la gestion et de contrôle des budgets au niveau de l'activité
Sonatrach/AVAL. Notre objectif final dans ce projet est l'adoption d'une approche
organisationnelle et méthodologique qui vise une automatisation de la gestion et du
contrôle des processus budgétaires et la mise en œuvre d'une solution généralisée pour
l'optimisation de la solution au niveau de l'activité AVAL. Une bonne prévision
budgétaire annuelle permet d’honorer les meilleures dépenses des clients et agents de
l’entreprise Sonatrach/AVAL. Les méthodes de prise en charge des flux utilisées seront
UML et Workflow, les outils de validation des modèles de conception seront
l’utilisation du Logiciel MagicDraw pour la génération des fichiers BPEL.
Mots-clés : Modèle, Système d’information, UML, Workflow, Processus métier, BPEL, Modélisation,
Validation, Représentation relationnelle, Activité budgétaire, Sonatrach/AVAL
Sommaire ii
Problématique et introduction générale …………..………………………….…………………….………..………..…… 01
Chapitre I : Modélisation d’un Système

1. Introduction ………………..…………………………….…………………………………….……………….………….….……………….… 05
2. L’approche orientée objet ………………..…………………………….…………………….……………………………...….…05
2.1. Introduction …………………………………………………..……………………….…………………………..…….……….…...…05
2.2. Concepts importants ……………………………………………………………………………………………………..………06
a. Classe et Objet …………………………………………………………..………………………..………………………………...……06
b. Association …………………………………………………………..………………………………..………………………………....…06
c. Agrégation …………………………………………..………………..………………………………..……………………………………07
d. Composition ………………………………………………………..…………………………………..…………………………….……07
e. Héritage, Spécialisation, Généralisation et Polymorphisme ………….………………….……07
3. Le Langage UML ………………..…………………………………………………………………………………………………..….…… 08
3.1. Introduction …………..…………………………………..…………………………………………………………….…..….….…08
3.2. Les diagrammes UML ………………………………………………………………………………….….……..…..….…08
3.3. Diagrammes de classes ……………………………………………………………………………….……………..…..…09
3.4. Diagrammes d’objets …………………………………………………....……………………………….….…………......10
3.5. Diagrammes de composants …………………………………………………………………….……..…….………11
3.6. Diagrammes de structures composites ………………………………………………………..…..………11
3.7. Diagrammes de déploiement ………………………………………………………..…………………….…………11
3.8. Diagrammes de package ………………………………………………..…………………………….…………….……12
3.9. Diagrammes de cas d’utilisation …………………………………………………………..…………….….……12
3.10. Diagrammes d’activités ……………………………………………………………………………….……….…….….…14
3.11. Diagrammes d’états-transitions ………………………………………..………………………..……..…..….…15
3.12. Diagrammes de séquence …………………………………………….…………………………….………………...…16
3.13. Diagrammes de communication ……………………………………………………………………….……...…18
4. Conclusion ………………..……………………..……………………………………………………………….………………..………...….… 19
Chapitre II : La technologie des WorkFlows
1. Historique ………………..…………………………….…….…………………………………….……………….……………….…….….…… 20
2. Introduction ………………..…………………………….……..……………………………………………….………………….….…...…… 20
3. Concepts clés ………………..………………………….……………………………………………………..……………….…….…….……21
3.1. Processus métier …………..…………………………..………………………………………………….…………………..………21
3.2. Modèle de processus ………………………………………………………………………………………….……………..……21
3.3. Tâche ……….………………………………………………………………………………………………………………….…………….……21
3.4. Nœud…………………………………………………………………………......………………………..…….……………………..….….…22
3.5. Types de nœuds ……………………………………………………………..…………………..……………….………….….……22
Sommaire iii
3.6. Transitions ……….………………………………………………………………………………………….….………………………..…. 22

3.7. Evènement …………………………………………………………………………………………………..…….…………..…….…...… 22
4. Workflow et processus métier …………………………………………………………………….………………..………… 22
5. Aperçu sur les Workflow ………………………………………………………………………..………………………….……… 23
5.1. Modèle de référence …………..…………………..………………………………………………….……………………………24
5.2. Système de gestion des Workflow ……………………………………………………………………………..……25
5.3. Workflow et business objects …………………………………………………………………….………………….……26
6. Application d’UML sur les Workflow …………………………..…………………………………………………… 27
7. Langages de spécification de Workflow …………………..…………………………………………….…….….. 30
8. Conclusion …………..…………………………………………………………………………………………………….…..………………....… 30
Chapitre III : Langage d’Exécution des processus métiers (BPEL)
1. Introduction ………………..…………………………….……..……………………………………………….……………….………….……31
2. Processus métier et fichier BPEL ………………..……….………….…………….……………….…………….……..……31
3. Concepts fondamentaux et syntaxe de BPEL ………………..…………..……….………………….….….… 31
3.1. Syntaxe des éléments de base …………..……………………………………………….…………………………….…32
3.2. Syntaxe des éléments basés sur les messages …………....……………………………………….………33
3.3. Syntaxe des éléments de contrôles structurés …………..……………………………………..…..……33
3.4. Syntaxe des éléments de contrôles évolués …………..………………………….………………………..34
Chapitre IV : Modélisation d’un processus métier par UML-Workflow
1. Définition ………………..…………………………….……..…………………………………………………….……………….………...…… 37
2. Aspects à modéliser………………..……….……………………………………………………….…………..……..……………..……37
2.1. Aspect fonctionnel…………..………………………………………………………..………………….………...…………………37
2.2. Aspect comportemental …………..…………………………………………….……………….……………………….……37
2.3. Aspect informationnel …………..………………………………………………………………….………………………..…38
2.4. Aspect organisationnel …………..……………………………………………….……………….……………….…….….…38
3. Présentation du système à modéliser ………………..……….…………………………….…………….....……..…39
3.1. Les objectifs stratégiques de la société SONATRACH ……….……………………….….……38
3.2. Les différentes structures de SONATRACH …………….……………….…………………………...…39
3.2.1. L’activité AVAL …………..………………………………………………..………………..….…………………….………39
3.2.2. La Direction d’Informatique et de Systèmes d’Information ……….……..….………40
3.2.3. Le Département Systèmes Informatique …………….…………………………………....……………41
3.3. Présentation du cahier de charges …………….…………………………………….…………………………...…41
3.3.1. Description de la procédure de l’élaboration du budget PA et PMT de
département ‘Production’ …………..……………………..……..………………..….……………………..………41
Sommaire iv
3.3.2. Description de la procédure de l’élaboration du budget PA et PMT de

département ‘Finances’ …………..……………………..……..……………………..….…………………….….…… 42
3.3.3. Description de la procédure de validation des prévisions de
consommations quantitatives pour les articles non gérés en stocks (M)
du plan annuel (PA) et PMT ……..……..……………………..……..………………………..…….….………45
4. Modélisation par UML ………………………………..………………………….……..……………………………………….…… 46
4.1. Modélisation statique ……….……………………………………………………………………………………......….………46
4.1.1. Diagramme de classes …………..………………………..………….………….……………………………….………47
4.2. Modélisation dynamique ……….………………………………………………………………………………………….…48
4.2.1. Diagramme d’activités de la fonction Production (P) …….…………..…………..…………49
4.2.2. Diagramme d’activités de la fonction Finances (F) …………..……..…….………….….……51
4.2.3. Diagramme d’activités de la fonction Validation des prévisions de
consommations non gérées en stock (M) ………………………………..……………….……….....…52
5. Modélisation par Workflow ………………………………….……..……….…………………………………………….…… 54
5.1. Eléments de diagrammes de processus Workflow ……….….……………………….……...……54
5.2. Modélisation des diagrammes de processus Workflow ….…….…………….………….……55
5.2.1. Diagramme de processus métier de la fonction production (P)…………..….....…56
5.2.2. Diagramme de processus métier de la fonction finance(F) …………………..........…57
5.2.3. Diagramme de processus métier de la fonction validation des
prévisions des consommations des articles non gérés en stock (M) ….....…...58
5.2.4. Diagramme de processus métier de la fonction Approvisionnement
(A)…………………………………..………………………………………………………………………...…………………...…….59
5.2.5. Diagramme de processus métier de la fonction Système d’information
et de Gestion (SIG)……………………….….………..…………….…….………………..…………………….….......60
5.2.6. Diagramme de processus métier de la fonction Administration et Social
(S)……….…………………………………………………….………………………………….…………………………….…….......61
5.2.7. Diagramme de processus métier de la fonction Service Relation de
Travail (RT)…….………………………………………………………………….…………………….……….….…........62
5.2.8. Diagramme de processus métier de la fonction Moyens Généraux
(M)……….……………………………………………….…………………………………….……………………………….….......63
5.2.9. Diagramme de processus métier de la fonction Ressources Humaines
(R)……….…………………………………………………….………………………………….….………………………………......65
5.2.10. Diagramme de processus métier de la fonction Passation des Marchés
(PM)……….……………………………………………….….…………………………….………………………….…………......66
5.2.11. Diagramme de processus métier de la fonction Assistant Sûreté Interne
(ASI)…….………………………………………………….………………………………….…………………………….………....67
5.2.12. Diagramme de processus métier de la fonction conseil syndical …..….....…68
5.2.13. Diagramme de processus métier de la fonction maintenance(G) ….........…69
5.2.14. Diagramme de processus métier de la direction de l’unité, D*E et D*S…...70
5.2.15. Diagramme de processus métier de la fonction technique(T) ….................…71
5.2.16. Diagramme de processus métier de la fonction sécurité industrielle(I)...72
Sommaire v
5.2.17. Diagramme de processus métier de la fonction travaux neufs(W) …......…73

prévisions des stocks, d’achats et de consommations des articles
gérés en stock (A) ………………………………………………………………………..….....…...74
prévisions des stocks, d’achats et de consommations des articles
non gérés en stock (A) ….....…………………………………………………………………………………………....76
prévisions consolidées d’achats et consommations articles non
gérés en stock (M) ….....………………………………………………………………………………………………….....77
Chapitre V : Validation des diagrammes de processus Workflow
5.1 Introduction…...……………………….……………………………………………………………………………………...…….…..….79
5.2 Génération des fichier de validation BPEL ………………………………………………...……….…..….79
5.2.1 Fichier BPEL du diagramme de processus métier de la fonction (P) …..….....82
5.2.2 Fichier BPEL du diagramme de processus métier de la fonction (F)……........85
5.2.3 Fichier BPEL du diagramme de processus métier de la fonction
validation des prévisions de consommations non gérées en stock (M)…....86
Chapitre VI : Architecture des processus métiers du système étudié et

Représentation relationnelle du système étudié
1. Introduction ………………..……….……………………………………………………..……………………….……………….………...……88
2. Architecture des processus métiers ………………..……….…………………………….……………….………...……88
2.1. Architecture du processus métier de département Production ………..…….………..88
2.2. Architecture du processus métier de département Approvisionnement …....90
2.3. Architecture du processus métier de département Maintenance………….………...91
2.4. Architecture du processus métier de département Sécurité industrielle …....92
2.5. Architecture du processus métier de département Moyens généraux ……......93
2.6. Architecture du processus métier de département Technique……………..……..…...94
2.7. Architecture du processus métier de département Travaux neufs………...….....95
3. Représentation relationnelle du modèle statique ……………………………….……………….…..……96
3.1. Règles de passage du modèle conceptuel au modèle relationnel……….…….……..96
3.2. Schéma du modèle relationnel relatif au modèle statique conçu………….…..……..96
Conclusion générale ……………………………………………………..……………………………………………………………...….….....98

Annexe 01 : Complément de diagrammes d’activités du système étudié ……………...100
Annexe 02 : Présentation intégrale du cahier de charges du système étudié ….…...117
Bibliographie : ………………………………………………………………………………………………………….…………………………......138
Problématique
&
Introduction générale
Problématique et Introduction Générale 1
Problématique et introduction générale
Le budget est un processus lourd et complexe à mettre en œuvre. Les entreprises

n’ont pas encore trouvé d’autres alternatives pour encadrer à la fois leurs investissements,
leurs dépenses, allouer les ressources nécessaires et donner des objectifs aux actions à venir.
Le premier rôle du budget est de donner un cadre pour l’exercice à venir. Le budget décline
insuffisamment la stratégie de l’entreprise au niveau opérationnel.
En somme, le budget est décrit comme mobilisant des ressources considérables
pour une utilité discutée. Pour être plus dynamique et en adéquation avec les orientations
stratégiques, il devrait être réactualisé plus fréquemment.
Les entreprises doivent constamment faire preuve de capacité d’adaptation et procèdent à
des révisions tarifaires fréquentes. Les mutations fréquentes au sein de l’entreprise
impactent le processus budgétaire. A cet égard, l’entreprise doit être dotée d’un processus
budgétaire évolutif et capable d’appréhender les modifications de structure. Les données
saisies doivent pouvoir être manipulées en cours d’exercice afin de prendre en compte ces
changements parfois considérables (fusion/ désinvestissement).
La construction du budget au sein des structures AVAL/Sonatrach est très majoritairement
réalisée par tableur où la consolidation des données devient très complexe.
Les outils utilisés manquent de flexibilité pour appréhender les évolutions de l’entreprise et
de capacité à suivre l’intégralité des flux d’informations. Les outils limités dans leur
fonctionnalité favorisent les dysfonctionnements.
Le contrôle de gestion est un processus transversal destiné à aider les responsables

de service à piloter leurs activités et à agir dans le sens de la stratégie, il a un rôle d'interface
entre le plan stratégique et opérationnel. Il permet d'obtenir l'assurance que les ressources
sont obtenues et utilisées de manière efficace (atteindre les objectifs) et efficiente (utilisation
des ressources). Le budget est un outil classique et en général un outil central du contrôle de
gestion, puisque c’est à travers de son élaboration que sont précisés les objectifs de
l’entreprise et que sont définis les objectifs de chaque manager et les moyens qui seront mis
à sa disposition sur l’exercice considéré.
La gestion budgétaire est un mode de gestion qui englobe tous les aspects de l'activité de
l'organisation qui comprend une période de budgétisation (construction de l'ensemble
cohérents de prévisions chiffrées) puis une période de contrôle budgétaire.
La gestion et le contrôle budgétaire au niveau de l’activité AVAL/Sonatrach n’adopte pas de
technique et de méthode automatique suffisante à la solution du processus budgétaire sus
Conception d’un Processus de Développement par UML-WorkFlow

mentionnée. Les difficultés à ce niveau peuvent être vues classées en deux catégories : des
problèmes de gestion et des problèmes de contrôle.
D’autre part, la circulation des supports budgétaires se fait d’une manière manuelle et ainsi
les flux de communication deviennent moins contrôlables.
En contre partie, les problèmes liés au contrôle budgétaire concernent notamment la mise à
jour des fichiers Excel utilisés aux différents niveaux. Ces mises à jour sont achevées d’une
manière rudimentaire et aléatoire et le manque d’un mécanisme automatique pour ce
traitement (mise à jour des fichiers Excel) induit à une absence de traçabilité des historiques
des différents accès et opérations appliqués. En somme, toutes les transactions et les accès
effectués sur les fichiers à chaque niveau (service de validation) pour les différentes
structures ne sont pas pris en charge et l’unité budgétaire ne conçoit qu’une version finale
qui n’indique aucune trace des modifications antérieures.
Le problème lié au flux d’information de l’unité budgétaire a aussi un aspect sécurité :
identification des accès, gestion des authentifications et autorisation pendant les échanges
d’information au sein de l’unité de production, des divisions et direction.
Le projet de l’automatisation de la gestion et du contrôle budgétaire devient donc
une nécessité prioritaire.
Afin de permettre aux responsables de l’activité AVAL de la société nationale
SONATRACH de réaliser ce projet, nous allons concevoir un système d’information relatif à
l’élaboration des prévisions budgétaires des différentes structures de l’activité AVAL.
Mais tout d’abord quelle démarche pouvons nous suivre pour aboutir à notre
objectif ?
Selon [01], vu la complexité croissante des systèmes d’information, de nouvelles
méthodes et outils ont été créées. La principale avancée réside dans la programmation
orientée objet (P.O.O.).
Ce nouveau mode de programmation a rapidement montré les limites des méthodes de
modélisation classique (telle MERISE).
La prise de conscience de l'importance d'une méthode spécifiquement objet ("Comment
structurer un système sans centrer l'analyse uniquement sur les données ou uniquement sur
les traitements, mais sur les deux"), ne date pas d'hier. Plus de 50 méthodes objet sont
apparues durant le milieu des années 90 (Booch, Classe-Relation, Fusion, HOOD, OMT,
OOA, OOD, OOM, OOSE...). Aucune ne s'est réellement imposée.
Dans ce contexte et devant le foisonnement de nouvelles méthodes de conception «
orientée objet », l’OMG1 a eu comme objectif de définir une notation standard utilisable dans
les développements informatiques basés sur l’objet. C’est ainsi qu’est apparu UML (Unified
1
L’OMG (Object Management Group) est une association américaine à but non-lucratif créée en 1989 dont l’objectif est
de standardiser et promouvoir le modèle objet sous toutes ses formes. L’OMG est notamment à la base des
spécifications UML, MOF, CORBA et IDL. L’OMG est aussi à l’origine de la recommandation MDA [20].

Modified Language), qui est issu de la fusion des méthodes Booch, OMT (Object Modelling
Technique) et OOSE (Object Oriented Software Engineering).
Issu du terrain et fruit d'un travail d'experts reconnus, UML est le résultat d'un large
consensus. De très nombreux acteurs industriels de renom ont adopté UML et participent à
son développement.
En l'espace d'une poignée d'années seulement, UML est devenu un standard
incontournable pour élaborer des modèles objet indépendamment de tout langage de
programmation. Il permet tout à fait de modéliser les activités (c'est-à-dire la dynamique)
d'un processus, de décrire le rôle des acteurs du processus, la structure des éléments
manipulés et produits, etc…
Devant la diversité des langages de programmation orientée objet, UML apparaît
comme une espèce de standardisation graphique de ces langages, reprenant tous les
mécanismes de base de l’orienté objet, même si leur traduction dans ces langages diffère.
Cela permet aux personnes impliquées dans le développement logiciel de restreindre de
plus en plus leur apport à la seule conceptualisation et analyse, en se libérant des contraintes
syntaxiques propres aux langages et en différant de plus en plus les détails techniques liés à
l’implémentation [ 11].
Grâce à UML, les objets s’envolent. Concrètement, un programmeur C++ et un
programmeur Java, C#, Python ou PHP, pourront travailler, pour l’essentiel, dans un
langage graphique commun, et automatiser, autant que faire se peut, la traduction des
diagrammes dans les différents langages [11].
L’utilisation des workflow dans les entreprises permet l’automatisation des
différents processus de l’entreprise. Ceci conduit le concept de processus à occuper
aujourd’hui une place majeure dans le domaine des systèmes d’information [02].
Les entreprises se trouvant actuellement sur le marché ont bien compris les
avantages que l’utilisation des systèmes de gestion de workflow pouvait leur apporter :
gains de productivité, allocation plus efficace des ressources, maîtrise de la complexité
inhérentes à de grands projets [03].
Comme le définit [04], UML est un « langage graphique destiné à la modélisation
de systèmes et de processus et il consiste en une série de symboles et de connecteurs qui
peuvent être utilisés pour créer des diagrammes de processus». D’autre part, Les
diagrammes de processus métiers de workflow sont très comparables aux diagrammes
d’activité UML, de par leur fonctionnement et leur représentation.
Finalement, ces points forts spécifiques à UML nous ont encouragés de procéder à
une démarche basée sur la modélisation UML-Workflow afin de concevoir notre futur
système d’information.
Outre l’introduction générale et la conclusion générale, ce mémoire est composé

de six chapitres. Dans le premier chapitre, nous allons parler de l’approche orientée objet et
du langage UML. Le deuxième chapitre sera consacré pour la technologie workflow. Une
présentation du langage BPEL (Business Process Execution Language) « langage
d’exécution des processus métiers » sera donnée dans le troisième chapitre. Notre

contribution sur la modélisation statique UML (Diagramme de classes) , la modélisation

dynamique UML-Workflow basée sur le principe des diagrammes d’activités sera présentée
dans le quatrième chapitre. Dans le chapitre cinq nous allons procéder à la validation de ces
derniers diagrammes en utilisant le logiciel MagicDraw pour les implémenter et les
transformer en fichiers BPEL sous format XML. En fin, nous allons présenter notre
contribution sur la conception des architectures des différents processus métiers relatifs à
l’élaboration des prévisions budgétaires, suivie de la représentation relationnelle de notre
modèle statique conçu.

Chapitre 1
Modélisation d’un Système

Chapitre I – Modélisation d’un système 5
1. Introduction
Selon [05], un modèle est une représentation abstraite et simplifiée (i.e. qui exclut
certains détails), d’une entité (phénomène, processus, système, etc.) du monde réel en vue de
le décrire, de l’expliquer ou de le prévoir. Modèle est synonyme de théorie, mais avec une
connotation pratique : un modèle, c’est une théorie orientée vers l’action qu’elle doit servir.
Concrètement, un modèle reflète ce que le concepteur croit important pour la
compréhension et la prédiction du phénomène modélisé, les limites du phénomène modélisé
dépendant des objectifs du modèle.
Modéliser un système avant sa réalisation permet de mieux comprendre le
fonctionnement du système.
C’est également un bon moyen de maîtriser sa complexité et d’assurer sa cohérence. Un
modèle est un langage commun, précis, qui est connu par tous les membres de l’équipe et il
est donc, à ce titre, un vecteur privilégié pour communiquer. Cette communication est
essentielle pour aboutir à une compréhension commune aux différentes parties prenantes
(notamment entre la maîtrise d’ouvrage et maîtrise d’œuvre informatique) et précise d’un
problème donné.
Un modèle définit une frontière entre la réalité et la vision du concepteur. Ce n’est pas la
réalité, mais une vue très subjective de la réalité[03].
Le choix du modèle a donc une influence capitale sur les solutions obtenues. Les systèmes
non triviaux sont mieux modélisés par un ensemble de modèles indépendants. Selon les
modèles employés, la démarche de modélisation n’est pas la même.
2. L’approche orientée objet
2.1 Introduction
Dans l’approche orientée objet, tout système est vu comme un ensemble d’objets
dissociés, identifiés et définis par des propriétés. Une propriété est soit un attribut (i.e. une
donnée caractérisant l’état de l’objet), ou entité élémentaire comportementale de l’objet. La
fonctionnalité du système émerge alors de l’interaction entre les différents objets qui le
constituent. L’une des particularités de cette approche est qu’elle rapproche les données et
leurs traitements associés au sein d’un unique objet [05].
Comme nous venons de le dire, un objet est caractérisé par plusieurs notions :
L’identité : L’objet possède une identité, qui permet de le distinguer des autres objets,
indépendamment de son état. On construit généralement cette identité grâce à un identifiant
découlant naturellement du problème (par exemple un produit pourra être repéré par un
code, une voiture par un numéro de série, etc.) [05].
Les attributs (Propriétés) : Ils représentent des variables stockant des informations sur l’état
de l’objet.

Les méthodes : L’ensemble des actions (opérations) que l’objet va réaliser est déterminé par
ses méthodes. Ces opérations permettent de faire réagir l’objet aux sollicitations extérieures
(ou d’agir sur les autres objets). De plus, les opérations sont étroitement liées aux attributs,
car leurs actions peuvent dépendre des valeurs des attributs, ou bien les modifier.
La difficulté de cette modélisation consiste à créer une représentation abstraite,
sous forme d’objets, d’entités ayant une existence matérielle (voiture, ampoule, personne,...)
ou bien virtuelle (client, temps,...).
2.2 Concepts importants
Nous avons vu que l’approche objet rapproche les données et leurs traitements.
Cette approche manipule un ensemble de concepts importants [ 12]:
a. Classe et Objet : Une classe est la description formelle d’un ensemble d’objets ayant
une sémantique et des propriétés communes. Elle représente des éléments concrets
(ex. des départements), des éléments abstraits (ex. des formations) ou des
composants d’une application (ex. les boutons des boites de dialogue).
Un objet est une instance d’une classe. Il représente une entité du
monde réel. Par exemple, Finances est une instance de la classe département.
Notation graphique
Nom de la classe
- attribut_1 : Int
…
- attribut_n : String
+ opération_1() : void
…
+ opération_m() : void
Figure 1.1- Représentation graphique d’une classe d’objets
b. Association : L’association décrit le lien statique entre plusieurs classes.
Notation graphique
Nom d’association
Classe1 Classe2
Figure 1.2- Représentation graphique d’une association
 Une association est dite réflexive si elle représente un lien entre des objets de
la même classe.
Personne
Est père de
Figure 1.3- Exemple d’association réflexive

c. Agrégation : C’est une forme particulière d’association où un tout est relié à ses
parties. Le tout (la classe du côté du losange) est appelé agrégat et la classe en
opposé est appelé agrégé (c.f : figure 1.4).
Produit Commande
Figure 1.4- Exemple de relation d’agrégation
d. Composition : Lorsque que la suppression de l’objet agrégat mène à la suppression

des objets agrégés, on dit que l’agrégation est forte, il s’agit donc d’une composition.
Graphiquement, on ajoute un losange plein (◆) du côté de l’agrégat (cf. figure 1.5).
Commande Ligne Commande

Figure 1.5- Exemple de relation de composition
e. Héritage, Spécialisation, Généralisation et polymorphisme : L’héritage est un

mécanisme de transmission des propriétés (attributs et méthodes) d’une classe
(classe mère ou super classe) vers une sous-classe (classe fille). Une classe peut être
spécialisée en d’autres classes, afin d’y ajouter des caractéristiques spécifiques ou
d’en adapter certaines. Plusieurs classes peuvent être généralisées en une classe qui
les factorise, afin de regrouper les caractéristiques communes d’un ensemble de
classes.
Ainsi, la spécialisation et la généralisation permettent de construire des hiérarchies
de classes. L’héritage peut être simple ou multiple. L’héritage évite la duplication et
encourage la réutilisation.
Le polymorphisme représente la faculté d’une méthode à pouvoir s’appliquer à des
objets de classes différentes.
Notation graphique Personne

Matricule
Nom
Prénom
Date de naissance
Vaccances(…)
DossierMédical(…)
Employé Etudiant
Date de recrutement Date d’inscription
Grade de l’employé Niveau d’inscription
Calculer le salaire(…) Spécialité d’étude
Calculer la moyenne annuelle(…)
Figure 1.6- Représentation graphique d’héritage entre la classe mère « Employé »

et ses deux classes filles « Etudiant » et « Personne ».

3. UML
3.1 Introduction
Selon [05], les méthodes utilisées dans les années 1980 pour organiser la
programmation impérative (notamment Merise) étaient fondées sur la modélisation séparée
des données et des traitements. Lorsque la programmation par objets prend de l’importance
au début des années 1990, la nécessité d’une méthode qui lui soit adaptée devient évidente.
UML (Uniﬁed Modeling Language en anglais, soit langage de modélisation objet
uniﬁé) est né de la fusion des trois méthodes qui s’imposaient dans le domaine de la
modélisation objet au milieu des années 1990 : OMT, Booch et OOSE. D’important acteurs
industriels (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.) s’associent alors à l’effort
et proposent UML 1.0 à l’OMG (Object Management Group) qui l’adopte en novembre 1997
dans sa version 1.1 comme langage de modélisation des systèmes d’information à objets. La
version d’UML en cours à la fin de 2006 est UML 2.0 qui s’impose plus que jamais en tant
que langage de modélisation standardisé pour la modélisation des systèmes, utilisé sur des
centaines de projets dans le monde ; en conséquence, la connaissance d’UML est désormais
une des compétences qui sont exigées quasi systématiquement lors d’un recrutement.
3.2 Les diagrammes UML

Un diagramme UML est une représentation graphique, qui s'intéresse à un aspect
précis du modèle [06]. C'est une perspective du modèle et non pas "le modèle".
UML 2.0 propose treize types de diagrammes pour décrire les concepts particuliers
d’un système. Ils se répartissent en deux grandes catégories [12] :
A. Diagrammes structurels ou diagrammes statiques (UML Structure)

– diagramme de classes (Class diagram)
– diagramme d’objets (Object diagram)
– diagramme de composants (Component diagram)
– diagramme de structures composites (Composite structure diagram)
– diagramme de déploiement (Deployment diagram)
– diagramme de paquetages (Package diagram)
B. Diagrammes comportementaux ou dynamiques (UML Behavior)

– diagramme de cas d’utilisation (Use case diagram)
– diagramme d’activités (Activity diagram)
– diagramme d’états-transitions (State machine diagram)
– Diagrammes d’interaction (Interaction diagram)
– Diagramme de séquence (Sequence diagram)
– diagramme de communication (Communication diagram)
– diagramme global d’interaction (Interaction overview diagram)

– diagramme de temps (Timing diagram)

 Nous allons présenter les principaux diagrammes UML.
3.3 Diagramme de classes (Class Diagram)
3.3.1 Définition
Le diagramme de classes est considéré comme le plus important de la modélisation
orientée objet, il est le seul obligatoire lors d’une telle modélisation. Il permet de fournir une
représentation abstraite des objets du système et les différents types de relations statiques
qui existent entre eux.
3.3.2 Propriétés de classe

Une classe décrit un ensemble d’objets dotés de propriétés (attributs). Les
propriétés d’un objet permettent de spécifier son état et son comportement.
La syntaxe d’une propriété est la suivante :
<visibilité> [ / ] <nom_attribut>:
<Type> [ ’[’ <multiplicité> ’]’ [ ’{’ <contrainte> ’}’ ] ] [ = <valeur_par_défaut> ]
 Visibilité : Elle indique si l’attribut est public (+) ou privé (-)

 Type : Il peut être un nom de classe, un nom d’interface ou un type de donné
prédéfinie
 Multiplicité : Elle indique le nombre de valeurs possibles de l’attribut.
 Contrainte : pour préciser si les valeurs sont ordonnées ({ordered}).
3.3.3 Méthodes de classe

Une opération (même nom et même types de paramètres) doit être unique. La
déclaration d’une opération contient les types des paramètres et le type de la valeur de
retour, sa syntaxe est la suivante :
<visibilité> <nom_méthode> ([ <paramètre> [, <paramètre> [, <paramètre> ...] ] ]) :
[<valeur_renvoyé>] [ { <propriétés> } ]
La syntaxe de définition d’un paramètre (<paramètre>) est la suivante :
[<direction>] <nom_paramètre>:<Type> [’[’<multiplicité>’]’] [=<valeur_par_défaut>]
La direction (<direction >) peut prendre l’une des valeurs suivante :

in : Paramètre d’entrée passé par valeur. Les modifications du paramètre ne sont pas
disponibles pour l’appelant. C’est le comportement par défaut.
out : Paramètre de sortie uniquement. Il n’y a pas de valeur d’entrée et la valeur finale est
disponible pour l’appelant.
inout : Paramètre d’entrée/sortie. La valeur finale est disponible pour l’appelant.
Le type du paramètre (<Type>) peut être un nom de classe, un nom d’interface ou un type de
donné prédéfini.

Les propriétés (<propriétés>) correspondent à des contraintes ou à des informations

complémentaires comme les exceptions, les pré-conditions, les post-conditions ou encore
l’indication qu’une méthode est abstraite (mot-clef abstract), etc.
3.3.4 Association entre classes

Une association est une relation entre deux classes(association binaire cf. figure 1.7)
ou plus (association n-aire cf. figure 1.8), qui décrit les connexions structurelle entre leurs
instances. Elle est représentée par une ligne pleine et peut être ornée d’un nom, avec une
précision du sens de lecture (► ou ◄).
Etudiant
1..* Travaille ► 1 1..*
Employé Organisme
1..* 1..1
Figure 1.7– Association binaire Module Enseignant
Figure 1.8– Association n-aire

3.3.5 Cardinalité
Elle indique le nombre d’objets d’une classe qui peuvent participer à l’association.
Elle est généralement définie avec une borne inférieure et une borne supérieure. Si les deux
bornes sont égales on utilise un seul nombre, dont ‘1..1’ est représentée par ‘1’, et ‘0..*’ par ‘*’
(infinie)
3.3.6 Classe d’association (associative)

Lorsqu’une association possède des propriétés caractérisant le lien entre les classes
associées, celle-ci est remplacée par une classe appelée classe associative et les propriétés du
lien deviennent attributs de cette classe.
Une classe-association est caractérisée par un trait discontinu entre la classe et
l’association qu’elle représente (Figure 1.9).
Enseignant Module
Enseigner
Nombre d’heures
Figure 1.9 – Exemple de classe d’association

3.4 Diagramme d’objets (object Diagram)
Le diagramme d’objets représente un instantané des objets d’un système à un
moment donné [06]. Il est souvent appelé diagramme d’instance, car il représente des
instanciations de classes et non pas des classes (cf. figure 1.10).

D:Département
Département
nom : String= ’’Informatique’’
nom : String
1..* est affecté à est affecté à
est affecté à
est affecté à
1..*
Enseignant E1 :Enseignant E3 : Enseignant E2 : Enseignant
Figure 1.10 – Exemple de diagramme de classes et de diagramme d’objets associé (à droite).
3.5 Diagrammes de composants

Les diagrammes de composants permettent de décrire l’architecture physique et
statique des applications d’un système donné en termes de modules (fichiers, sources,
librairies, …) [12].
Nom du composant
Figure 1.11 – Représentation graphique d’un composant
 Généralement le concept composant est également très utilisé dans la

conception des interfaces graphiques ( Un bouton, une zone de saisie… sont
des composants [06].
3.6 Diagrammes de structure composite

Ces diagrammes font partie des nouveautés ramenées par UML 2.0. Ils permettent
de décomposer hiérarchiquement une classe en une structure interne [06].
Commande
Ligne de commande
Figure 1.12 – Un diagramme de structure composite décrivant une commande
3.7 Diagramme de déploiement (Deployment diagram)
Les diagrammes de déploiement représentent l’agencement physique d’un

système montrant sur quels composants matériels les différents composants logiciels
s’exécutent (cf. figure 1.13) [06]. Les principaux éléments sont des nœuds connectés par des
voies de communication. Un nœud représentera une unité qui va héberger un logiciel, un
équipement matériel ou ordinateur, un environnement d’exécution, un système
d’exploitation, … etc.

BD
Département Utilisateur
administration
Serveur
BD Employé BD
BD Finance
Département
formation et
information
BD Client
Figure 1.13 – Un diagramme de déploiement
3.8 Diagramme de package (Package diagram)

Les diagrammes de package permettent de grouper les éléments UML dans des
unités de plus haut niveau selon leurs types, leurs fonctionnalités ou leurs architectures. Ils
sont plus souvent utilisés pour grouper des classes.(cf. figure 1.14) [06].
Facturation Comptabilité
Facture Client Ecriture comptable
Produit Plan comptable national
Figure 1.14 – Exemple d’un diagramme de package
3.9 Diagramme de cas d’utilisation (Use Case Diagram)

Les diagrammes de cas d’utilisation décrivent le comportement d’un système, tel
qu’un utilisateur le voit. Ils permettent donc d’exprimer le besoin des utilisateurs d’un
système.
3.9.1 Éléments des diagrammes de cas d’utilisation
a) Acteur : Selon [08], un acteur est une entité du modèle organisationnel
participant à l’accomplissement d’une procédure. il est chargé de réaliser les
activités qui lui sont attribuées via le(s) rôle(s) qui lui sont définis dans le
modèle organisationnel. Il se représente par un petit bonhomme (Figure 1.15)
avec son nom (son rôle).
b) Cas d’utilisation : Un cas d’utilisation modélise un service rendu par le
système en réponse à un besoin d’un acteur. Il doit produire un résultat
observable pour un ou plusieurs acteurs du système [12] . Il se représente par
une ellipse (Figure 1.15) contenant le nom du cas (un verbe à l’infinitif), et
optionnellement, au-dessus du nom, un stéréotype.

 Un cas d’utilisation non relié directement à un acteur, est appelé cas

d’utilisation interne.
c) Relation : Elle exprime l’interaction existant entre un acteur et un cas
d’utilisation. On distingue principalement deux types de relations :
- Les dépendances stéréotypées représentées par une flèche avec un trait
pointillé.(les plus utilisés sont l’inclusion et l’extension).
- La généralisation / spécialisation représentée par une flèche avec un trait
plein dont la pointe est un triangle fermé désignant le cas le plus général.
C.1) Relation d’inclusion : Elle indique que le cas d’utilisation source contient le
comportement décrit dans le cas d’utilisation destination. Cette dépendance

est symbolisée par le stéréotype « include » (figure 1.15 tirée de [05]).
C.2) Relation d’extension : Cette relation indique que le cas d’utilisation source
précise le cas d’utilisation destination. Elle permet de modéliser les variantes

d’un cas d’utilisation. Le stéréotype utilise est « extend ».
C.3) Relation de généralisation : Un cas A est une généralisation d’un cas B si B est
un cas particulier de A [05].

 La seule relation possible entre deux acteurs est la généralisation : un acteur A
est une généralisation d’un acteur B si l’acteur A peut être substitué par l’acteur
B. Dans ce cas, tous les cas d’utilisation accessibles à A le sont aussi à B, mais
l’inverse n’est pas vrai [05].
Borne interactive d’une banque
Retirer de
l’argent
Client << include >>
Effectuer un virement
Extension Points :
Vérification_solde (après : S’authentifier
avoir demandé le montant) << include >>
Condition :{si montant >100}
Point d’extension : << extend >>
vérification_solde
Vérifier le solde << include >>
Consulter comptes
Consulter depuis internet
Figure. 1.15 - Exemple de diagramme de cas d’utilisation

3.10 Diagramme d’activités (Activity diagram)
Comme les définit [05], les diagrammes d’activités décrivent le comportement

d’une méthode, le déroulement d’un cas d’utilisation et les cheminements d’activités. Ils
permettent de mettre l’accent sur les traitements. Ils sont donc particulièrement adaptés à la
modélisation du cheminement de flots de contrôle et de flots de données.
3.10.1 Eléments de diagramme d’activités
a) Activité : Une activité désigne une suite d’actions et représentée par un

rectangle aux coins arrondis.
b) Nœuds : Un nœud est un type d’élément abstrait permettant de représenter les

étapes le long du flot d’une activité [05]. On distingue deux types de nœuds :
nœud d’exécution (d’action) et nœuds de contrôle. Les nœuds de contrôle
sont : nœud initial, nœud de fin, nœud de décision, nœud de fusion, nœud de
bifurcation et nœud d’union.
c) Transition : Les transitions sont utilisées pour connecter les activités entre
elles, elles sont représentées par des flèches en traits pleins. Elles sont
déclenchées dès que l’activité source est terminée et provoquent
automatiquement et immédiatement le début de la prochaine activité à
déclencher (l’activité cible). Contrairement aux activités, les transitions sont
franchies de manière atomique, en principe sans durée perceptible [05].
d) Couloirs d’activités : Les couloirs d’activités servent à organiser le diagramme

d’activités selon les acteurs participants à l’exécution des taches représentées.
Il est possible de citer les objets principaux manipulés d’activités en activités.
3.10.2 Décision / Fusion
Le comportement conditionnel est décrit par des décision/fusion (figure 1.16)

Une décision (ou branchement) permet de représenter des transitions
conditionnelles en utilisant des gardes (expressions booléennes).
Une fusion marque la fin d’un comportement conditionnel.
3.10.3 Débranchement et jonction (Synchronisation)
Il est possible de synchroniser les transitions à l’aide des barres de synchronisation.

Ces dernières permettent d’ouvrir (débranchement) ou de fermer (jonction) des branches
parallèles au sein d’un flot d’exécution.
 Les transitions partant d’un débranchement ont lieu en même temps.
Une jonction n’est franchie qu’après réalisation de toutes les transitions qui s’y
rattachent.

3.10.4 Exemple de diagramme d’activités tiré de [05]
Figure 1.16 – Un diagramme d’activité décrivant la prise en compte d’une commande
3.11 Diagrammes d’états-transitions (machine d’états)
3.11.1 Introduction
Le diagramme d’états-transitions UML décrit le comportement d’un objet durant

son cycle de vie. Il permet plus précisément de décrire les changements d’état d’un objet, en
réponse aux interactions avec d’autres objets ou acteurs [05].
3.11.2 Eléments de diagramme d’états-transitions
a) Etat : Un état représente une période dans la vie d’un objet pendant laquelle ce
dernier attend un évènement ou accomplit une activité.
Dans un diagramme d’états-transitions, Un état simple (élémentaire) est
représenté par un rectangle aux coins arrondis (Cf. figure 1.17)
Arrêt
Figure 1.17 - Exemple d’état simple
 Les états qui contiennent des sous-états sont appelés composites.

L’état initial est un pseudo état qui indique l’état de départ, l’état final est un
pseudo état qui indique que le diagramme d’états-transitions, ou l’état
enveloppant, est terminé.
b) Transition : une transition représente le passage instantané d’un état vers un
autre [06]. Elle est automatique dans l’absence d’étiquette.
c) Etiquette : une transition peut être déclenchée par un évènement, conditionné à
l’aide de ’gardes’, et /ou être associée à une activité [06].
La syntaxe d’une transition est la suivante [05]:
[ <évènement> ][ ’[’ <garde> ’]’ ] [ ’/’ <activité> ]
Dont : - évènement est un déclencheur d’un changement d’état.
- garde est une condition booléenne exprimée en langage naturel.
- activité est un comportement exécuté pendant la transition.
3.11.3 Exemple de diagramme d’états-transitions tiré de [06]

Produit disponible
Confirmation Commande en /livrer Commande
Commande
passée cours livrée
Annulation Annulation Facture payée
Commande rejetée Commande clôturée
Figure 1.18 - Diagramme d’états-transitions décrivant une commande
3.12 Diagramme de séquence (Sequence diagram)
3.12.1 Définition
Les diagrammes de séquence ont pour objectif la représentation des interactions

entre objets selon un point de vue temporel. L’accent est mis sur la chronologie des
échanges[12].
Notation graphique
Objet 1 Objet 2 Objet 3

Ligne de
Envoi de vie d’un
message objet
Figure 1.19 – Représentation graphique de diagramme de séquence

 L’ordre d’envoi de message est déterminé par sa position sur l’axe vertical du
diagramme ; le temps s’écoule de haut en bas de cet axe.
La disposition des objets sur l’axe horizontal n’a pas de conséquence pour la
sémantique du diagramme [06].
3.12.2 Barre d’activation

Il est possible de représenter de manière explicite les différentes périodes d’activité
d’un objet en utilisant une bande rectangulaire superposée à la ligne de vie de l’objet [06].
 Un dédoublement de la barre indique un message récursif [06].
3.12.3 Appels synchrones et asynchrones

Un message définit une communication particulière entre des lignes de vie. Dans
un message synchrone, l’appelant attend la réponse afin de poursuivre son traitement, alors
que dans un message asynchrone, il continue son traitement sans attendre de réponse.
Le message synchrone est représenté par un trait plein orienté par une flèche
pleine, tandis que le message asynchrone est représenté par un trait plein orienté par une
flèche vide.
3.12.4 Instructions itératives et conditionnelles

Il est possible de représenter une exécution conditionnelle, itérative ou parallèle
d’un message en utilisant des cadres d’interactions et en précisant la clause alt, loop et par,
pour respectivement alternative, itération et parallèle.
3.12.5 Création et suppression de participants

La création d’un participant se fait en traçant une flèche de message allant
directement vers la boite du participant.
La suppression d’un participant est indiquée par un grand X.
 Une flèche de message entrant dans X signifie qu’un participant supprime un autre.
Un X mis à la fin d’une ligne de vie montre qu’un participant se détruit lui-même
(autodestruction) [06].
3.12.6 Exemple de diagramme de séquence tiré de [06]

: Ligne de : Produit
: Commande
commande
Calculer montant
Loop [Pour chaque ligne]

Avoir quantité
Avoir produit
Avoir tarification
Calculer
somme
Figure 1.20 - Exemple de diagramme de séquence
3.13 Diagrammes de communication (Communication diagram)
3.13.1 Définition
Un diagramme de communication (diagramme de collaboration dans UML.1.x) est

souvent utilisé pour illustrer un cas d’utilisation ou pour décrire une opération. Il décrit
l’interaction en mettant l’accent sur les liaisons des données entre objets participant à
l’interaction.
3.13.2 Synchronisation des messages
Dans un diagramme de communication, nous pouvant préciser l’ordre et les

conditions d’envoi des messages, en indiquant pour chaque message :
- Les clauses qui conditionnent son envoi,
- Son rang (son numéro d’ordre par rapport aux autres messages),
- Ses arguments ou paramètres (optionnels),
- Le nom du message.
 La numérotation des messages est faite par des chiffres séparés par des points. Ainsi il
est possible de représenter le niveau d’emboîtement des messages et leur précédence [06].

3.13.3 Exemple
Dans la figure 1.21 ci-dessous tirée de [06], l’envoi du message 1.2 suit
immédiatement celui du message 1.1 et ces deux messages font partie du flot des messages 1.
1 Calculer montant()
1.5.1 Avoir réduction()

Client
Commande
1.5 Calculer
réduction
1.1 Avoir quantité 1.3 Avoir tarification()
1.2 Avoir produit
Ligne de Produit
commande
Figure 1.21 - Exemple de diagramme de communication
4. Conclusion
Comme nous l’avons déjà dit, UML n’est qu’un langage de modélisation. En effet,
UML ne propose pas une démarche de modélisation explicitant et encadrant toutes les
étapes d’un projet, de la compréhension des besoins à la production du code de
l’application.
Bien qu’UML ne soit pas une méthode, ses auteurs selon [05], précisent néanmoins pour la
modélisation d’un système, qu’une méthode basée sur l’utilisation UML doit être itérative et
incrémentale, pilotée par les cas d’utilisation et en fin centrée sur une architecture conçue
principalement pour satisfaire les besoins exprimés dans les cas d’utilisation et prendre en
compte les évolutions futures et les contraintes de réalisation.

Chapitre 2
La Technologies des WorkFlows

Chapitre II - La Technologie des Workfolw 20
1. Historique
D’après [09], l'industrie de l'imagerie électronique et de la gestion de la production

assistée par ordinateur a été la première à réclamer une technologie qui permette
l’automatisation des procédures de travail, jusqu’alors réalisées à la main.
À partir de l’année 1975 et jusqu’à 1985, la nouvelle technologie dite de WorkFlow a connu
un essor important par la mise en place d'un système capable d’automatiser au mieux les
flux de travail. Ainsi des systèmes de WorkFlow statique ont vu le jour : Officetalk-P,
Backtalk, Poise, Xerox InConcert, etc.
De nombreuses entreprises ayant développé des produits similaires n’ont pu passer le cap
du millénaire, car les outils réalisés étaient grevés par un prix élevé et une complexité
importante. L’échec du WorkFlow statique est principalement dû au fait qu’il était très
difficile d’intégrer et de modifier les procédures de travail dans les systèmes WorkFlow. Les
traitements et les données faisaient partie intégrante du système et rendaient la tâche ardue.
Le regain d’intérêt pour le génie logiciel au début des années 1990 a permis de relancer les
recherches concernant les systèmes WorkFlow afin de mettre en place des systèmes plus
simples à utiliser. Il s’en est suivi une véritable explosion quant aux systèmes élaborés, dont
Oval, Apricot, MelMac, WAMO, FreeFlow, etc. Ces systèmes, connus sous le nom de
WorkFlow générique, proposaient une nouvelle approche du WorkFlow. L’idée était de
séparer traitement et données relatives aux procédures de travail et d'offrir de la sorte une
plus grande facilité quant à la création, la modification ou la suppression des procédures de
travail.
2. Introduction
La technologie des WorkFlows (WFs) s’impose actuellement dans le domaine de la

réalisation et la gestion des activités des organisations. Lorsque l’exécution des opérations
d’un WF se fait de manière automatique, des composantes spécialisées, appelées Business
Objects (BOs), sont introduites pour prendre en charge ces opérations et assurer leurs
réalisations.
Le WorkFlow Management Coalition (WFMC) définit un WF comme une
automatisation totale ou partielle d’un processus métier, durant lequel des documents, des
informations ou des tâches, sont transférés d’un participant à un autre pour des besoins et
fins spécifiques [16]. Ce transfert se base sur un ensemble de règles préétablies [17].
L’interaction d’un WF avec ses divers participants se fait par des WorkLists (WL). Le WFMC
définit un WL comme étant une liste d’activités à exécuter par un participant spécifique (ou
parfois par un groupe de participants).
L’Object Management Group (OMG) définit un BO comme étant une

représentation d’un élément actif dans le domaine des affaires. Un BO est décrit par ses

attributs d’affaires, son comportement, ses relations avec l’environnement intérieur et

extérieur et ses contraintes.
L’approche WF est l’une des nouvelles technologies de modélisation des systèmes

mises à la dispositions des concepteurs. Cette approche a pour objectif la coordination et le
suivi des processus métiers dans une organisation et par conséquent, d’identifier qui est
responsable de quoi[18].
3. Concepts clés
3.1 Processus métier
Un processus métier est un ensemble de procédures et d'activités plus au moins

liées qui réalisent collectivement un objectif métier [17 et 18], en général au sein d'une
structure organisationnelle définissant des rôles et des relations fonctionnelles. Un processus
métier peut être entièrement inclus dans une organisation simple ou peut s'étendre sur
plusieurs organisations.
Un processus métier peut combiner des activités automatiques et des activités manuelles
(WfMC).
3.2 Modèle de processus
C’est la représentation d'un processus métier dans une forme qui supporte des
manipulations automatiques comme la modélisation ou l'exécution par un système de
gestion de workflow. Une telle définition consiste en un réseau d'activités, en des critères
pour indiquer le démarrage et la terminaison du processus, ainsi que des informations sur
les activités comme les participants, les applications et les données permettant la mise en
œuvre des processus.
3.3 Tâche
Un processus métier est constitué d’un ensemble de tâches liées par des
transitions[10]. Une tâche peut être manuelle ou automatique. Pour s'exécuter, elle utilise
des ressources humaines et/ou machines. Quand une ressource est requise, la réalisation de
l'activité est attribuée à un participant.
a. Tâche automatique : une activité qui s'exécute sur un ordinateur et qui est
entièrement contrôlée par le système de gestion de processus
b. Tâche manuelle : une activité non automatisée qui reste en dehors du contrôle du
système de gestion de processus.
 Ces activités peuvent cependant être inclues dans la définition d'un processus à des
fins de modélisation.

3.4 Nœud : Action interne à l'application mais n'ayant pas d'interaction ni avec
l'utilisateur ni avec un élément externe.
3.5 Types de Nœuds

 Un (unique) startNode : étape à l'origine de la création de l’instance
du workflow
 TaskNode : étape en attente d'une interaction avec l'utilisateur
 State : étape en attente d'une action extérieure (webservices, attente de
réponse d'un composant externe à l'application)
 Un ou plusieurs endNode : Archivage de l'instance du workflow et libération
des ressources
 Les nœuds task et state ont un état wait
 Fork : Séparation du workflow en N branches devant se réunir via un nœud
de type Join
 DecisionNode : Condition sur une variable de l'instance de workflow
(utilisation d'un langage simple ou délégation à une classe java)
3.6 Transitions : Elles sont utilisées pour relier tout ces nœuds, représentant le
changement d'un nœud à un autre au sein de l'instance.
Une transition est un point dans l'exécution d'une instance de processus où une
activité se termine et une autre démarre.
Une transition peut être inconditionnelle (la terminaison de l'activité précédente
déclenche le démarrage de l'activité (ou des activités) suivante(s)) ou
conditionnelle (ce déclenchement est gardé par une condition logique).
3.7 Evènement : Chaque nœud possède trois évènements déclencheurs.
 onNodeEnter : déclenchée à l'entrée du nœud

 onNodeLeave : déclenchée à la sortie du nœud courant
 onTransition : déclenchée lors de la transition du nœud suivant un événement
n'est pas lié qu’à une action, mais peut déclencher plusieurs
actions.
 Un nœud n'a pas à connaître l'existence des autres nœuds, il manipule un

ensemble de données dans un contexte d'exécution.
4. Workflow et processus métier
Pour [15], un Workflow est une représentation d’un processus métier dans un
format interprétable et compréhensible par la machine.

Pour illustrer la relation entre les termes ‘‘Workflow’’ et ‘‘processus métier’’, nous
pouvons dire que le premier s’intéresse à l’organisation d’un travail (métier ou autre)
représenté par la coordination automatisée des tâches. Il correspond à la représentation
schématique ou à la modélisation d’un processus métier, alors que le deuxième (processus
métier) représente le métier proprement dit de l’entreprise en termes d’activités, de rôles et
de règles métiers.
Donc, et selon [07], un processus Workflow est explicitement défini comme étant
un ensemble d’étapes. Chaque étape peut-être une activité, une tâche (activité atomique) ou
peut faire référence à un sous-processus. Les activités sont exécutées via les conditions de
transition. Une activité peut être manuelle ou automatisée. Elle est réalisée par un rôle qui
décrit les compétences et le savoir faire qu’un acteur (utilisateur du Workflow ou
participant) doit avoir au sein d’une organisation. L'exécution de ces activités demande
l’invocation de ressources (applications externes, outils informatiques, etc.), la manipulation
de données, ainsi que l’accès aux artefacts tels que documents, formulaires électroniques ou
feuilles de styles.
5. Aperçu sur les WFs
D’après [17], deux étapes sont nécessaires pour la mise en place d’un WF, à savoir:
Création des processus et gestion des processus. Dans la première étape, une description des
processus est élaborée en termes de composants et de moyens de support. Tant dis que La
gestion assure le suivi et le contrôle des instances de processus actifs dans le système.
Pour que les WFs puissent être utilisés de manière efficace, il est important qu’ils intègrent
les capacités suivantes [21]: supporter les changements des modèles de processus; permettre
la surveillance de l’exécution des processus; permettre la distribution des processus à travers
des domaines d’affaires; et supporter l’assignation des ressources et étapes des processus.
Selon [16], l’utilisation des WFs peut intervenir à plusieurs niveaux dans une organisation.
Ainsi, un WF destiné-image permettrait d’automatiser le flot de documents papiers qui
circulent dans l’organisation. Pour cela, les documents sont transférés en images digitales.
Un WF destiné-formulaire permettrait de router de manière intelligente les formulaires dans
l’organisation. Ces formulaires, différents des images digitales, contiennent des champs
d’édition dont les valeurs sont exploitées dans les opérations de routage. De plus, ce type de
WF peut notifier ou rappeler ses usagers de certaines actions spécifiques à prendre en
compte. Enfin, un WF destiné-coordination permettrait de faciliter l’accomplissement des
opérations nécessitant l’intervention de plusieurs personnes. Pour cela, un cadre de
collaboration basé sur les engagements pris par ces personnes est nécessaire.

5.1 Modèle de Référence
Le standard prédominant dans la structuration d’un WF est le modèle de référence

du WFMC. Ce modèle présente une perspective orientée-WFs distribués [19]. La Figure 2.1
tirée de [16] illustre un environnement où plusieurs WFs cohabitent avec d’autres éléments :
services réseau et clients des WFs (clients pouvant être déconnectés du réseau de
communication).
Service réseau Serveur WF

(imprimante)
Réseau WAN
(Internet)
Client WF (mobile)
Serveur WF
Figure 2.1 - Environnement de WFs distribués
Selon [16], les WFs distribués sont des applications basées sur des processus qui
s’exécutent sur une infrastructure réseau à grande échelle (tel que l’Internet) et hétérogène.
Pour assurer le fonctionnement d’une telle infrastructure, certaines exigences doivent être
satisfaites [19] : hétérogénéité des composants faisant partie du WF, participation évolutive
et flexible au WF, support «Plug and Play» aux applications et BOs, discontinuité des
opérations et enfin, décomposition récursive et dynamique des WFs.
La figure 2.2 présente les composants de base du modèle de référence d’un WF ainsi que les
interfaces entre ces composants [19].
Figure 2.2 - Modèle de référence d'un WF

 Le modèle de référence d’un WF définit cinq composants, selon [16]:
1. Outils de construction/définition des processus : outils utilisés pour spécifier dans une
notation abstraite la logique de fonctionnement des processus.
2. Serveur WF : centre nerveux du système WF, en étant responsable de la gestion des
processus et des WLs, des services de répertoire des participants et des invocations
d’applications externes.
3. Application client : application graphique destinée à la gestion des WLs d’un usager sur le
serveur WF.
4. Applications externes : ressources utilisées par le serveur WF pour compléter les activités
des processus.
5. Outils d’administration et de surveillance : outils utilisés pour suivre l’exécution des
processus.
 Le modèle de référence d’un WF dispose de cinq interfaces entre ses composants :

 Interface 1 - serveur-concepteur: définit un format commun pour l’échange des
spécifications des processus statiques entre l’outil de définition des processus et le
serveur WF.
 Interface 2 - client-serveur : supporte les interactions entre l’application client du WF et le
serveur WF. Ces interactions incluent les WLs, la demande d’informations et de contrôle
des processus WFs et de leurs activités et enfin, les fonctions administratives. Cette
interface permet également à une application client d’un vendeur d’interagir avec le
serveur WF d’un autre vendeur (interopérabilité WF/Application Usager).
 Interface 3 - invocation d’applications : n’est pas disponible pour le moment mais elle
devrait décrire comment des ressources externes sont invoquées par le serveur WF.
 Interface 4 - serveur-serveur : (interopérabilité WF/WF) décrit les interactions entre les
serveurs WFs. Ces interactions incluent l’initiation, la demande d’informations et de
contrôle des processus WFs et de leurs activités et les fonctions administratives.
 Interface 5 - surveillant-serveur : définit les fonctions d’administration et de surveillance
du serveur WF.
5.2 Système de Gestion des WFs
Le Système de Gestion d’un WF (SGWF) joue le même rôle qu’ un système de

gestion de base de données, il représente l’infrastructure de support d’un WF et de ses
processus métiers.
Selon [16], au moment de la conception d’un SGWF, le défit est de concevoir un
environnement dans lequel diverses technologies, allant des bases de données au traitement
distribué, doivent être intégrées de manière simple et flexible. En fait, chaque technologie
impliquée dans le fonctionnement d’un WF a ses caractéristiques fonctionnelles et

structurelles. Par conséquent, les questions d’interopérabilités de systèmes surgissent de

nouveau.
Un SGWF supporte les fonctionnalités des WFs par le biais de deux modules : modélisation et
exécution. Le module de support à la modélisation fournit les primitives nécessaires à la
définition des composants suivants : activités, entités responsables de l’exécution des
activités, données et flux de contrôle entre les activités et enfin, les conditions de début (pré)
et de fin (pro) d’exécution des activités. L’imbrication de WFs fait également partie de ce
module [16].
Comme [16] l’a définie, l’entité responsable de l’accomplissement d’une activité peut être un
programme ou une personne. Lorsqu’il s’agit d’une personne, cette information est définie
dans une Base de Données (BD) orientée-personnes («staff»). Les définitions d’un WF sont
également stockées dans une BD orientée-activités. Il est à noter que les deux BDs sont
généralement gérées par un SGBD sous-jacent au WF en question et peuvent être mises à
jour à tout moment. Les activités d’un processus de WF présentent plusieurs caractéristiques
énumérées comme suit :
 Dépendance entre activités : séquentiel, parallèle, alternatif ou conditionnel.
 Compensation des résultats des activités.
 Comportement «roll-back» pour des activités.
5.3 WFs et BOs
Selon [16], un BO est une entité capable d’exécuter des opérations nécessaires à la
satisfaction des besoins de ses utilisateurs. Parmi ceux-ci, les WFs qui font souvent appel aux
BOs afin de supporter leurs processus métiers.
Dans l’objectif de structurer un BO de manière flexible et de lui assigner des responsabilités
bien spécifiques, une architecture à cinq niveaux est proposée dans [22]. Ces niveaux sont :
présentation, Processus métiers, entités d’affaires, accès aux données et stockage des données.
La couche présentation assure l’interaction entre les usagers et les entités d’affaires. Les
interactions se résument à un échange d’informations. Une entité d’affaires caractérise les
services qui sont communs à différentes opérations. Ces services sont représentés par des
règles d’affaires.
À titre d’exemple tiré de [16], une application de gestion de comptes bancaires intègre le
service «déduire un montant d’une balance». Un processus métier est une séquence de
traitement qui requiert les services de plusieurs entités d’affaires. La responsabilité d’une
entité d’affaires est de fournir les services reliés au domaine d’application. Cette entité ne
doit pas être concernée par le stockage et la récupération des caractéristiques de ce domaine.
Par conséquent, cette fonctionnalité est associée à la couche de stockage des données. La
couche de stockage des données intègre les fonctionnalités d’accès à une base de données
spécifique. Les entités d’affaires interagissent avec la couche de stockage de données grâce à
la couche d’accès aux données. La couche d’accès fournit les services aux entités d’affaires au

niveau de la création de nouvelles entités, la récupération d’une entité d’affaires déjà

existante dans la base de données et la mise à jour et récupération des entités. Finalement, la
couche processus métier demande les services de la couche d’accès aux données pour
débuter ou terminer une transaction [16].
6. Application d’UML sur les WFs

Comme nous avons vu, UML est le fruit de l’effort de standardisation de divers
formalismes de méthodes de conception orientés-objet disponibles sur le marché. Dans
l’objectif de créer un environnement homogène entre les usagers, consultants et
développeurs, UML est suggéré dans la description des systèmes.
Un système à modéliser est constitué d’un ensemble de processus et de structures statiques. Le
modèle d’un processus est représenté par une séquence d’activités, exécutées pour atteindre
un but défini. Par conséquent, les diagrammes de séquence et d'activités d’UML sont
appropriées pour une spécification des processus métiers de manière conviviale aux usagers.
Pour les structures statiques d’un système, les diagrammes de structures statiques d’UML
peuvent être utilisées sans la nécessité d’introduire des détails d’implantation [16].
La figure 2.3 tirée de [16] montre des exemples de représentation de processus métier, des
objets d’affaires et de rôles dans des équipes dans UML [23]. Les objets d’affaires sont
représentés par des objets et classes d’UML. Les classes représentent des objets d’affaires
sans identité, tel que Facture. Les objets représentent des objets d’affaires qui ont une
identité, tels que Facture numéro 2/98. Les processus métiers sont représentés par des Use-
Cases et des instances de Use-Cases d’UML.
Selon [16], les WFs sont des processus métiers automatisés (pouvant aussi être partiellement
automatisés). Ils sont représentés comme des Use-Cases ou des instances de Use-Cases avec
le stéréotype «WorkFlow». Les rôles dans des équipes sont représentés par des objets et
classes d’UML. Les classes représentent des types de rôles, alors que les objets représentent
des personnes associées à des rôles spécifiques. Tous les symboles peuvent être ornés par un
stéréotype approprié, comme «BO», «Processus métier » et «Rôle dans Équipe».

Figure 2.3 - Représentation d'un BO, d'un processus métier et d'un rôle dans
une équipe dans UML
La figure 2.4 tirée de [16] est un diagramme de structure statique d’UML. Il montre une
structure d’équipe[23]. Les rôles dans l’équipe sont représentés comme des instances
d’objets, ce qui permet de spécifier le nombre de personnes dans chaque rôle. Dans
l’exemple de la figure 2.5, l’équipe de satisfaction des besoins des clients comporte trois
développeurs, deux testeurs et un gestionnaire de produits. Le regroupement des rôles est
représenté par le symbole d’un «package».
Figure 2.4 - Structure d'équipe par un diagramme de structure statique d’UML

La figure 2.5 tirée de [16] montre un diagramme de séquence d’UML, qui est utilisé pour
représenter une instance d’un processus métier. L’acteur client passe une commande à un
employé non spécifié du département des ventes. Cet employé procède à la validation de la
commande. Si celle-ci est valide, cet employé invoque une instance du processus métier,
appelé «la compagnie délivre l’article». Ce type de diagramme n’est pas explicitement
mentionné dans le guide de Notation d’UML. Par contre, il reste conforme au méta-modèle
d’UML. Les symboles au-dessus des lignes verticales représentent des rôles de classification.
Ces rôles sont acteur, objet et UseCase.

Figure 2.5 - Instance d'un processus métier par un diagramme de séquence d’UML
Dans la figure suivante tirée de [16] , le diagramme de Use-Cases d’UML représente les
relations statiques entre les processus métiers. Un processus métier décrit les collaborations
qui existent entre l’organisation et les clients.
Figure 2.6- Relations statiques entre processus métiers par un diagramme de

Use-Cases d’UML
La figure 2.7 tirée de [16] représente le diagramme d’activités d’UML, qui est utilisé dans la
définition d’un package de Use-Cases destiné à la gestion des factures.
Figure 2.7 - Chronologie des processus métiers par un diagramme d'activités UML

7. Langages de spécification de workflow

Beaucoup de langages de spécification de processus métiers sont apparus ces
dernières années. Chacun adopte sa terminologie particulière et définit ses concepts
spécifiques en fonction des objectifs visés par le méta-modèle2 de Workflow, du domaine
d’intérêt ou du choix de représentation. Ces spécifications sont techniques et sont basées sur
le langage XML.
Parmi ceux-ci, nous pouvons citer :
– WSFL : le langage Web Services Flow Language développé par IBM

– BPML : le langage Business Process Modeling Language développé par l’organisation
BPMI.org (Business Process Management Initiative).
– XLANG : le langage XLANG [13] a été développé par Microsoft en 2001, pour les besoins
de sa plateforme de gestion de processus BizTalk. Ce langage permet de représenter les
éléments clés, d’un point de vue algorithmique, des processus métier et se classe ainsi
dans les langages de description comportementale.
– BPEL4WS : le langage BPEL4WS [13] est développé en 2003, par un regroupement
d’industriels, parmi ceux-ci, on retrouve IBM et Microsoft. Ce langage est une fusion des
langages, dit de première génération : XLANG et WSFL. Il reprend donc les avantages de
ces deux langages en tirant parti de l’apprentissage lié à leur mises en place. Il se focalise
sur la représentation du processus métier en se rapprochant des structures
algorithmiques.
Dans le chapitre suivant, nous allons présenter le langage BPEL, car il représente l’évolution,
dans le temps, des premiers langages de ce type, et plus particulièrement la fusion de WSFL
et XLANG. De plus il s’avère être le langage le plus utilisé par les industriels, devenant ainsi
un standard de fait, en plus d’être en phase de devenir un standard Oasis.
8. Conclusion
Dans ce chapitre, nous avons présenté de manière générale la technologie des WFs
et son importance dans la modélisation des processus métiers. Selon [16], un léger consensus
existe sur la définition d’un WF et de ses caractéristiques. Sous le terme de WF, les personnes
peuvent faire référence à un processus métier, à la spécification d’un processus, à un logiciel
qui implante et automatise un processus ou à un logiciel qui supporte simplement la
coordination et la collaboration de personnes implantant le même processus.
2
Selon MOF(Meta Object Facility), un méta-modèle définit la structure que doit avoir tout modèle conforme à ce méta-modèle. Tout modèle doit
respecter la structure définie par son méta-modèle.

Chapitre 3
Le Langage BPEL
Chapitre III - Langage d’exécution des processus métiers (BPEL) 31
1. Introduction
Selon [13], après une période très riche en création de nouveaux langages de
description comportementale, les acteurs majeurs tel que Sun, IBM, ou encore Microsoft se
sont associés pour écrire un nouveau langage, héritant des avantages des précédents. Ainsi,
la fusion des langages XLANG et WSFL a donné naissance à BPEL4WS connu sous le nom
de BPEL (Business Process Execution Language).
Avec BPEL nous pouvons définir des processus simples ou complexes. BPEL est similaire,
dans une certaine mesure, à des langages de programmation traditionnels. Il propose des
éléments de construction tels que boucles, branchements, variables, assignations, etc. ce qui
lui permet de définir les processus métiers de façon algorithmique. BPEL est un langage
spécialisé qui se concentre sur la définition et le développement de ces processus. Par
conséquent il offre d’un côté des éléments qui rendent cette définition relativement simple et
d’un autre côté, il est moins complexe que les langages de programmation traditionnels[14].
2. Processus métier et fichier BPEL

Nous avons vu qu’un processus métier décrit des interactions entre des agents
(personnes, services, organisations) et des systèmes d’information (logiciels, sous-systèmes).
Les différentes entités qui interagissent dans un processus donné sont les participants de ce
processus. Le processus métier est déterminé par un objectif précis : produire une facture
d’achat de fournitures, éditer un catalogue électronique, etc. Il est à la fois collaboratif et
transactionnel, et peut être composé d’activités automatisées aussi bien que manuelles. BPEL
utilise un vocabulaire XML permettant de spécifier et de décrire des processus métier [04].
Le fichier BPEL définit le processus, ou l’enchaînement et la logique des actions qui

seront exécutées par le moteur d’orchestration. La structure du fichier BPEL est la même que
celle du processus. Ce fichier est véritablement le code source de l’application que constitue
le processus, le moteur d’orchestration agissant comme une machine virtuelle capable
d’exécuter le code BPEL.
3. Concepts fondamentaux et syntaxe de BPEL

La description BPEL d’un processus métier est composée de quatre parties [13] :
– Une première partie permet de déclarer des variables, utilisant les types importés
de descriptions WSDL associées à la description BPEL. Ces variables seront
utilisées dans la partie description comportementale du processus métier pour
maintenir un état au niveau du service, et ainsi assurer des liaisons de données
entre deux opérations.
– Une deuxième partie permet la déclaration des partnerlinks : ces partnerlinks
définissent une liaison entre les ensembles d’opérations des services invoqués par

le service web BPEL et un nom de liaison bien précis du service BPEL. Ces liaisons
sont appelées partner et permettent ainsi d’identifier facilement les différents
services web utilisés.
– Une troisième partie permet la déclaration des fauthandlers : ce sont des processus à
déclencher en cas d’exception déclenchée pendant l’exécution du processus et non
interceptée avant.
– Enfin, la quatrième partie décrit le comportement du processus métier lui-même en
utilisant différents opérateurs dit de programmation.
3.1 Syntaxe des éléments de base tirée de [13]
 L’élément vide : c’est l’élément de base le plus simple : il permet d’insérer une
opération vide dans un processus. Ceci signifie que le processus ne fait rien, mais
ne se termine pas complètement l’instruction suivante sera exécutée. Ce processus
est très utilisé dans le cadre de la synchronisation des activités parallèles : il
supporte la gestion des links.
<empty standard-attributes>
standard-elements
</empty>
 L’élément de terminaison : cet élément force le processus métier à se terminer

immédiatement.
<terminate standard-attributes>
standard-elements
</terminate>
 L’élément d’affectation : cet élément permet d’affecter un nouveau contenu à une

variable.
< from variable="ncname" part="ncname"? query="queryString"?/>

<to variable="ncname" part="ncname"? query="queryString"?/>
 L’élément déclenchant une exception : cet élément permet de lever une exception
qui pourra être interceptée à différents niveaux.
<throw faultName="qname" faultVariable="ncname"? standard-attributes>

standard-elements
</throw>
 L’élément de délai : Il permet d’attendre un temps donné (for) ou jusqu’à une

certaine heure (until).
<wait (for="duration-expr" | until="deadline-expr") standard-attributes>

standard-elements
</wait>

3.2 Syntaxe des éléments basés sur les messages
 L’élément de réception : cet élément permet à un processus métier de se mettre en

attente (synchrone) d’un message : typiquement, la première opération d’un
serveur consiste à l’attente d’une demande de traitement envoyée par un client.
Cet élément est lié aux informations partnerLink et portType de la description WSDL
pour l’opération indiquée par l’attribut XML opération. Le contenu reçu peut être
affecté à la variable indiquée par l’attribut variable.
<receive partnerLink="ncname" portType="qname" operation="ncname" variable="ncname"?

createInstance="yes|no"? standard-attributes>
standard-elements
</receive>
 L’élément de réponse : Il permet à un processus métier de répondre à un message

qu’il aurait reçu par un receive. La combinaison d’un receive et d’un reply permet
de réaliser une opération de question/réponse tel que le définit WSDL, en mode
synchrone. Comme l’élément de réception, il est lié aux informations partnerLink
et portType de la description WSDL pour l’opération indiquée par l’attribut XML
opération. Le contenu envoyé peut provenir de la variable indiquée par l’attribut
variable.
<receive partnerLink="ncname" portType="qname" operation="ncname" variable="ncname"?

createInstance="yes|no"? standard-attributes>
standard-elements
</receive>
<reply partnerLink="ncname" portType="qname" operation="ncname" variable="ncname"?
faultName="qname"? standard-attributes>
standard-elements
</reply>
3.3 Syntaxe des éléments de contrôles structurés

Comme dans le langage XLANG, les contrôles structurés sont similaires à ceux
que l’on connaît des langages de programmation structurée. Leur corps est constitué
d’autres éléments de contrôle séquentiel ou des éléments de base ou d’échanges de
messages vu précédemment.
 L’élément de séquence : c’est l’élément permet d’exécuter de façon séquentielle
(dans l’ordre de lecture de la séquence) une ou plusieurs instructions BPEL (mot
clé activity). La séquence se termine elle-même lorsque le dernier processus la
constituant se termine.
<sequence standard-attributes>
standard-elements
activity+
</sequence>

 L’élément de choix: cet élément permet, comme en programmation structurée,

d’effectuer un branchement conditionnel : suivant l’évaluation d’une condition ou
d’un critère (attribut XML condition), le processus de la première branche (nœud
XML case) répondant à ce critère sera exécuté. Dans le cas où aucune condition ne
serait vraie, il est possible de définir une branche par défaut (nœud XML otherwise)
qui sera alors exécutée.
<switch standard-attributes>
standard-elements
<case condition="bool-expr">+
activity
</case>
<otherwise>?
activity
</otherwise>
</switch>
 L’élément de boucle : Il permet de réaliser une boucle while traditionnelle : la

boucle (composée des instructions représentées par le mot clé activity) est exécutée
tant que la condition (attribut XML condition) est évaluée à vrai.
<while condition="bool-expr" standard-attributes>

standard-elements
activity
</while>
3.4 Syntaxe des éléments des contrôles évolués

En plus des éléments de base et structurés vus précédemment, BPEL, comme le
langage XLANG, présente des outils allant du parallélisme d’actions à l’exécution
gardée (gestion des exceptions, évènements et aspect temporel).
 L’élément de parallélisme : c’est l’élément permet d’exécuter en parallèle plusieurs

processus (mot clé activity). Ces différents processus peuvent être indépendants, et
alors, le processus englobant l’exécution parallèle se termine lorsque tous ses
processus sont terminés. Ou alors, les processus peuvent être dépendants les uns
des autres, et l’utilisation de liens (links) permet de synchroniser où d’ajouter des
dépendances temporelles entre les différents processus. Ainsi, l’ensemble des liens
est annoncé dans la déclaration du processus parallèle et ensuite, chaque élément
des sous-processus peut utiliser les sources et les cibles (target) : une cible n’est
franchissable que si une source ayant le même nom a déjà été franchie (ou plus
exactement l’exécution du processus déclarant cette source est terminée).

<flow standard-attributes>
standard-elements
<links>?
<link name="ncname">+
</links>
activity+
</flow>
 L’élément Pick : Il regroupe différents processus dont l’exécution est gardée par :
- des évènements (nœud XML onMessage) : à l’arrivée d’un message, le processus
de la branche associée à ce message sera exécuté.
- un temps d’attente (nœud XML onAlarm) : au bout d’un temps d’attente donné,
le processus de la branche est exécuté.
Seule une branche est exécuté : le processus de la première branche dont la

garde est évaluée à vrai s’exécute.
Cet élément permet de gérer des évènements extérieurs au déroulement
normal de l’exécution. Par contre, l’espace temps possible, permettant l’arrivée de
ces évènements, est limitée par une garde temporelle. De plus, cette instruction a
une portée limitée entre deux autres instructions.
<pick createInstance="yes|no"? standard-attributes>

standard-elements
<onMessage partnerLink="ncname" portType="qname" operation="ncname"
variable="ncname"?>+
<correlations>?
<correlation set="ncname" initiate="yes|no"?>+
</correlations>
activity
</onMessage>
<onAlarm (for="duration-expr" | until="deadline-expr")>*
activity
</onAlarm>
</pick
 L’élément scope : c’est un élément très similaire à l’élément pick, et appelé context
dans le langage XLANG. Il permet d’exécuter un processus de façon gardée. C’est-
à-dire qu’il permet de parer à l’éventualité :
– d’une exécution du processus principal trop longue (nœud XML
eventHandlers) : une alarme est alors déclenchée et un processus associé à cette
alarme est exécuté.
– d’une exécution du processus principal déclenchant une exception (nœud
XML faultHandlers) : un traitement associé à cette exception est alors exécuté.

– de la survenue non prévue d’un message dans l’exécution du processus

principal (évènement extérieur) (nœud XML eventHandlers) : encore dans ce
cas, un processus associé à ce message est exécuté.
Cet élément représente les instructions traditionnelles trigger ou les blocs
try/catch. Contrairement à l’élément pick, sa portée n’est pas limitée entre deux
instructions, mais sur un bloc d’instructions (mot clé activity. Il définit également
un bloc compensationHandler permettant d’annuler les instructions réellement
effectuées en cas de mécanisme d’annulation de transactions.
<scope variableAccessSerializable="yes|no" standard-attributes>

standard-elements
<variables>?
...
</variables>
<faultHandlers>?
...
</faultHandlers>
<compensationHandler>?
...
</compensationHandler>
<eventHandlers>?
...
</eventHandlers>
activity
</scope

Chapitre 4
Contribution à la Modélisation
d’un processus métier de l’activité
budgétaire par UML-WorkFlow
Chapitre IV - Modélisation d’un processus métier par UML-Workflow 37
Dans ce présent chapitre nous allons proposer une démarche progressive fondée
sur l’utilisation d’UML-Workflow pour la modélisation d’un Système relatif à l’élaboration
des prévisions budgétaires du plan annuel (PA) et plan à moyen terme (PMT).
Après avoir étudié le cahier de charge présenté par l’équipe AVAL en exploitant
toute information considérée utile nous avons pu déterminer les acteurs impliqués dans
l’élaboration des prévisions budgétaires, l’ensemble de données pertinentes ainsi que les
différentes actions nécessaires pour l’exécution de ce processus important, en tenant compte
les objectifs fixés par les responsables.
Une bref définition de la modélisation est donnée en premier point, suivie d’une
description des différents aspects à modéliser en deuxième point, puis nous allons présenter
le système à modéliser en troisième point, en suite vient la modélisation statique par UML
et en fin ; nous aborderons la modélisation par workflow des diagrammes des processus de
l’élaborations des différentes prévisions budgétaires et de validations. Ces diagrammes sont
basés sur le principes des diagrammes d’activités UML.
1. Définition
La modélisation est une activité qui précède toute décision ou formulation, elle
permet de représenter la description du système réel. Cette description comporte un certain
nombre d’aspects à modéliser que nous allons présenter ci-dessous.
2. Aspects à modéliser
2.1. Aspect fonctionnel
L’aspect fonctionnel concerne l’identification des activités des processus que l’on
souhaite modéliser. Il est important de comprendre qu’il ne s’agit pas uniquement
d’identifier les fonctions des différents départements d’une organisation mais bien de
distinguer les activités composant un processus. La modélisation fonctionnelle doit
également permettre d’établir la hiérarchie des activités, c’est-à-dire d’exprimer de possibles
décompositions en termes de sous-processus. Enfin, le modèle fonctionnel doit aussi
représenter le flux de données associées aux activités et les interdépendances de données
entre les activités.
2.2. Aspect comportemental
L’aspect comportemental est un aspect primordial du Workflow puisqu’il

correspond à la dynamique du processus [07]. Le comportement s’exprime par la

modélisation d’un contrôle de flux entre les activités. Ce dernier permet d’indiquer la
chronologie de l’exécution des activités, leur flux (séquentiel ou parallèle), les points de
synchronisation entre activités ou au contraire, les points de disjonction.
De plus, le modèle comportemental doit représenter les évènements qui permettent de
déclencher les activités. L’aspect comportemental est également appelé aspect de
coordination.
2.3. Aspect informationnel (données)
Cet aspect concerne l’ensemble des informations et des données qui sont associées
aux activités. Le modèle informationnel, souvent négligé lors de l’implémentation d’un
Workflow, décrit en détail les relations qui existent entre les données, leur type et leur
structure [08].
2.4. Aspect organisationnel
Comme son nom l’indique, la partie organisationnelle concerne la description de

l’organisation des acteurs de l’entreprise. Le modèle organisationnel peut refléter fidèlement
l’organigramme de l’entreprise, c’est-à-dire la décomposition hiérarchique de celle-ci en
départements et services ou bien décrire des unités organisationnelles dans lesquelles on
identifie des acteurs. Selon la méthode choisie, la description est plus ou moins détaillée et
permet d’établir des liens hiérarchiques entre les acteurs ainsi que des relations entre unités
organisationnelles ou départements. Toutefois, quelle que soit la méthode retenue, la
description des rôles associés aux différentes activités reste invariante. Les rôles créent
l’interface entre le modèle organisationnel et les modèles représentant les activités.
3. Présentation du système à modéliser
SONATRACH (Société Nationale de Transport et de Commercialisation des

Hydrocarbures) est une société nationale pétrolière créée en date du 31 décembre 1963 par le
décret n° 63-491, elle se trouve actuellement en position de jouer un rôle de premier plan et
de consolider sa position internationale grâce à :
 L’importance de ses réserves énergiques dont 70% est en gaz naturel.

 Ses capacités de production des hydrocarbures liquides et gazeuses.
 Ses capacités technologiques et managériales.
SONATRACH est classée parmi les douze grandes compagnies pétrolières

mondiales. Ses principales actions sont :
 La recherche et l’exploration
 Le développement et l’exploitation des gisements

 Le transport des hydrocarbures

 La liquéfaction du gaz naturel et la transformation des hydrocarbures.
 Les opérations, l’association et le partenariat en amont et en aval de ses métiers.
SONATRACH est la première entreprise du continent africain. Elle est classée 11ème
parmi les compagnies pétrolières mondiales, 2ème de GNL et de GPL et 3ème exportateur du
gaz naturel.
3.1. Les objectifs stratégiques de la société SONATRACH
Les objectifs stratégiques de la société SONATRACH reposent sur :

 La maîtrise continue de ses métiers de base
 Le renforcement de ses capacités technologiques et managériales
 Le développement international et le partenariat
 La diversification de ses activités
3.2. Les différentes structures de SONATRACH
La SONATRACH est structurée en plusieurs structures appelées activités qui sont:

activité amont, activité aval, activité de transport et activité commerciale (Figure 4.1).
PDG
AMONT AVAL TRC COM
DGA Directions Régionales

Figure 4.1 – Organigramme des différentes structures de SONATRACH
3.2.1. L’activité AVAL
L’Activité AVAL a été créée pour la prise en charge de l’élaboration et la mise en

œuvre des politiques et stratégies de développement et d’exploitation de l’aval pétrolier et
gazier, et de leur mise en œuvre une fois approuvées.
L’activité Aval qui englobe les branches de raffinage pétrochimique (RPS) et de liquéfaction
et transformation des hydrocarbures a pour missions essentielles :

 D’exploiter les installations existantes de liquéfaction de gaz naturel et de séparation

des GPL.
 De mettre en œuvre, en partenariat le plan de développement de l’aval pétrolier et
gazier
 De suivre la gestion du portefeuille des filiales et participation confiée au holding
RCH.
Actuellement l’activité aval de SONATRACH est constitué de :
1. Quatre complexes de liquéfaction de gaz naturel GNL
2. Deux complexes de séparation des GPL
3. Trois filiales de production industrielle NAFTEC (raffinage), ENIP (Pétrochimie) et
HELIOS (Hélium)
4. Trois filiales de services : SOMIZ (Maintenance), SOMIK (Maintenance Skikda) et
SOTRAZ (Transport)
5. Deux autres filiales de services spécialisées en gestion de zone industrielle : EGZIA
(Arzew) et EGZIK (Skikda).
3.2.2. La Direction d’Informatique et de Systèmes d’Information
La Direction d’Informatique et de Systèmes d’Information a pour missions

essentielles :
 La contribution à l’élaboration des stratégies et politiques de l’entreprise en matière

d’informatique, de systèmes d’information, de télécommunication et de
documentation
 L’élaboration et la mise en œuvre du schéma directeur informatique de l’activité
AVAL.
 L’élaboration et la mise en œuvre des plans de développement des
télécommunications de l’activité AVAL
 L’appui aux projets de l’activité AVAL
 L’information et le reporting de l’activité AVAL.
La Direction d’Informatique et de Systèmes d’Information est organisée comme

suit :
 Le Département Systèmes Informatique (DSI)

 Le Département de Développement des Bases de Données (DDBD)
 LE Département de Gestion de l’Information et de la Communication (DGIC)
 Le Service de Télécommunications.

3.2.3. Le Département Systèmes Informatique
Ce département a pour rôle la conception, le développement, la mise en œuvre et

la maintenance des bases de données et des applications informatiques.
La conception et la réalisation de l’intégration du système d’Information (Data WareHouse ).
3.3. Présentation du cahier de charges
Nous nous limiterons à la présentation des trois procédures, deux relatives à

l’élaboration des prévisions budgétaires PA et PMT des deux départements de production
(P) et de Finances (F), l’autre correspond à la procédure de validation des prévisions de
consommations quantitatives pour les articles non gérées en stocks du département des
moyens généraux (M) du plan annuel et PMT.
 L’intégralité du cahier de charge est donnée en annexe 02.

3.3.1 Description de la procédure de l’élaboration du budget PA et PMT de
département ‘Production’.
Objectif : Ce budget exprime les consommations en matières premières nécessaires à

l’atteinte des objectifs de production arrêtés et les moyens de
fonctionnement internes à la structure.
a) Budget PA et PMT de la fonction production:
- Acteurs impliqués : Direction Exploitation LQS, D*E, P, G et A unité.
- Informations exploitées (input) :
 Plans : plan de production

 Paramètres de consommations en volume :
 produits chimiques (tamis moléculaires, inhibiteur de
corrosion…)
 énergies (électricité, utilités, eau, gaz naturel
autoconsommé, gaz industriels)
 lubrifiants
 carburants
- Prévisions de prestations de services : redevances d’occupations terre plein et

plan d’eau « STH »

b) Budget PA et PMT de fonctionnements de la structure P :
- Fournitures consommées (non régies par une norme) : Produits sociaux,

outillages, consommation de fournitures diverses et produits de
fonctionnement, fournitures de bureaux spécifiques, consommables
informatiques…
- Prestations de services : Nombre des missions par destinations.
Tableau descriptif
Acteur /
Action/ Description Destinataire Observation / support
Intervenant
EXP et dép. P Projet de Plan de production Plan de production
Elaboration et transmission des prévisions PA (par

Dép. P mois pour N et N+1) et PMT (de N+2 à N+5) de
consommation de :
 Matières et fournitures gérées en stock Pour prise en compte

liées à la production (quantitatifs selon Dép. A dans le budget achat A
paramétrages)
 Matières et fournitures pour Pour compléter budget

fonctionnements non régies par une achat A
norme, non gérées en stock et liées à la Dép. A
production (prévisions quantitatives)
 Matières et fournitures pour

fonctionnements non régies par une Pour compléter budget
norme, non gérées en stock et non liées Dép. M achat M
à la production (prévisions
quantitatives)
Pour intégration dans le
 Energies (prévisions valorisées) Dép. F budget trésorerie
Elaboration et transmission des prévisions

quantitatives de missions pour PA (par mois pour Dép. M Etat des missions
N et N+1) et PMT (de N+2 à N+5). détaillé (annexe)
Elaboration et transmission des prévisions Pour intégration dans le

valorisées de prestation de services pour PA (par Dép. F budget trésorerie
mois pour N et N+1) et PMT (de N+2 à N+5)
3.3.2 Description de la procédure de l’élaboration du budget PA et PMT de

département ‘Finances’
Objectif : Ce budget a pour objectif de déterminer pour l’ensemble de l’Unité,

essentiellement, les prévisions des:
 Impôts et taxes,
 Assurances,
 Dotations aux amortissements,

 Frais bancaires
 Prestations de services prévues par Finances.
a) Budget PA et PMT élaboré par finances:
- Acteurs impliqués : Toutes les structures de l’Unité et autres structures

AVAL (DAG, FIN, DRIZ………….)
 Fichier investissement et le plan d’investissement Unité (pour le

calcul des amortissements)
 Plan de production (taxe GN auto consommé, ..)
 Patrimoine à assurer (contrats d’assurances, plan
d’investissement et valeurs des stocks)
 Plan d’approvisionnement
 Le nombre de contrats et montants prévisionnels à régler aux
fournisseurs de biens et services locaux et étrangers pour
déterminer les services bancaires en rapport avec les modes de
paiements.
 Listing des véhicules légers et utilitaires réel
 Prestations inter unité (frais de siège DG et AVAL, participation
financière, …….)
 Paiements pour compte (redevances téléphoniques, salaires des
cadres supérieurs, contrats groupés Aval,…)
 Plan des consommations valorisés (A et M)
 Prestations de services valorisées de toutes les structures
 Prix GN autoconsommé retenu comme norme
 Soldes des comptes comptables de dettes et créances par natures
de dépenses.
- Informations (output) :
 Prévisions d’impôt et taxes

 Prévisions d’assurances
 Prévisions dotations aux amortissements
 Prévisions des frais bancaires (commissions,……
 Prévisions des prestations inter-unités
 Valorisations des prévisions de GN autoconsommé
- Prévisions de prestations de services : honoraires avocats, commissaires-
priseurs, notaires.

b) Budget PA et PMT de fonctionnements de la structure F :
 Fournitures consommées (non régie par une norme) : produits sociaux,

fournitures diverses et fournitures de bureaux.
 Prestations de services : Nombre des missions par destinations.
Tableau descriptif
Observation /
Acteur / Intervenant Action / Description Destinataire
support
Toutes les structures
de l’unité et autres Voir les informations exploitées (input) Dép. F
structures AVAL
Elaboration et transmission des prévisions PA

(par mois pour N et N+1) et PMT (de N+2 à Dép. M Pour
N+5) de consommation de fournitures non compléter
régies par une norme, non gérées en stock budget achat
Dép. F (prévisions quantitatives) M
quantitatives de missions pour PA (par mois
pour N et N+1) et PMT (de N+2 à N+5) Dép. M Etat des
Dép. F Elaboration des prévisions valorisées de missions
prestations de services prévues par Dép. F détaillé
pour PA (par mois pour N et N+1) et PMT (de
N+2 à N+5)
Elaboration des prévisions valorisées PA (par

mois pour N et N+1) et PMT (de N+2 à N+5) : Pour
 Dotation aux amortissements intégration
Dép. F  Prévisions prestation inter-unité dans le
 Impôts et taxes budget de
 Assurances trésorerie
Dép. F  Frais bancaires Annexe
 Valorisations des prévisions de GN
autoconsommé
Dép. F
Consolidations des prévisions valorisées des
charges (Unité) pour PA (par mois pour N et
N+1) et PMT (de N+2 à N+5)
Consolidations des prévisions valorisées des

produits (Unité) pour PA (par mois pour N et
N+1) et PMT (de N+2 à N+5)
Elaboration des prévisions de trésorerie

(Unité) pour PA (par mois pour N et N+1) et
PMT (de N+2 à N+5)

3.3.3 Description de la procédure de validation des prévisions de

consommations quantitatives pour les articles non gérées en stocks
(M) du plan annuel et PMT
1ère validation
- les prévisions sont saisies par les chefs de services, successivement et enregistrées
par centres de coûts jusqu’à leurs 1er validation.
- Affichage sur le tableau, seulement, des articles qui ont été quantifiés
(mouvementés).
- Les services valideront les prévisions enregistrées.
- La modification ou la suppression d’une prévision validée par le chef de service
nécessite le déverrouillage par le chef de département de rattachement.
2ème validation
 Après 1ère validation des chefs de services, les prévisions validées des services seront
affichées par tableau (un tableau par service) au niveau du chef de département de
rattachement.
 Apres la validation par tableau des prévisions de consommations quantitatives par
les chefs de structures (non rattache à D*E ou D*S) les prévisions seront exploitées
par le département M et peuvent être consultées par F.
 La modification ou la suppression des prévisions validées par les chefs de
structure nécessite le déverrouillage par le chef de département M.
3ème validation (pour les départements rattachés à D*E ou D*S)

 Apres 2eme validation, les prévisions annuelles seront affichées par tableau (un
tableau par département) au niveau du D*E ou D*S.
 Apres la validation par tableau des prévisions de consommations quantitatives par
D*E ou D*S les prévisions seront exploitées par le département M et peuvent être
consultées par F.
 Toutes modifications ou suppressions suivant le niveau de validation suit la même
démarche d’approbation.

4. Modélisation par UML
Comme nous l’avons vu au chapitre 1, une modélisation UML repose sur une
consolidation mutuelle de deux points de vue complémentaires : dynamique et statique. Les
aspects dynamiques sont représentés par des diagrammes d’activités. Tant dis que les
aspects statiques sont exprimés sous la forme de cas généraux dans le diagramme de classes.
4.1. Modélisation statique
En appliquant ce que nous avons vu dans le chapitre 1, nous allons représenter

dans la figure 4.2 les différentes classes et associations relatives à la modélisation statique du
système étudié.

Figure 4.2 - Diagramme des Classes correspondant au système étudié

4.2. Modélisation dynamique
Les diagrammes de flux et de données réalisés sont en nombre de vingt, parmi eux
seize sont relatifs aux processus de l’élaboration des prévisions budgétaires effectués par les
différents départements et directions et les autres quatre diagrammes décrivent les différents
processus de validation.
Nous allons présenter trois diagrammes d’activités correspondant aux procédures
d’élaborations des prévisions budgétaires PA et PMT des départements ‘Production’ et
‘Finance’, et celle de la validation des prévisions de consommations quantitatives pour les
articles non gérés en stocks (M) du plan annuel et PMT. Le reste des diagrammes se trouve
en annexe 01.

4.2.1 Diagramme d’activités du budget PA et PMT élaborées par le département

Production (P)
 Description du processus (P) :
Dès la réception du plan de production et la note accompagnée de la directive

cadre, le département Production (P) commence à élaborer en parallèle les prévisions PA et
PMT de consommations des matières et fournitures tout en respectant les paramètres et
normes en vigueur, les prévisions quantitatives PA et PMT de missions et les prévisions
valorisées PA et PMT de prestation de services.
Une fois l’élaboration des prévisions est terminée :

- l’acteur (P) transmettant à l’acteur département Finance (F) ses besoin en matière de
prestation de services pour prise en charge dans le budget de trésorerie.
- Il transmet aussi ses prévisions de missions à l’acteur département Moyens Généraux (M).
pour établir un état de missions détaillé.
- Si le consommable est de prévisions des énergies l’acteur (P) envoie ses prévisions à
l’acteur (F) pour qu’elles soient intégrées dans son budget de trésorerie.
- Si non, deux cas de figures peuvent se présenter :
- Si il s’agit de prévisions de consommation non liée à la fonction production, il transmet ses
prévisions à l’acteur (M) afin de lui permettre de compléter son budget d’achat (M).
- Si non, il transmet les prévision à l’acteur chef de service (CS). Ce dernier a pour rôle la
saisie et l’enregistrement des prévisions.
- Si l’acteur (CS) constate des anomalies il les communique à l’acteur (P) pour correction et
actualisation.
- Si non, exécution de la tâche de validation des prévisions par l’acteur ‘CS’.
- L’acteur ‘CS’ communique les prévisions validées à l’acteur ‘chef de département (CD)’
pour consultation.
- Si l’acteur (CD) constate des anomalies effectue un déverrouillage pour permettre à l’acteur
(CS) de faire les modifications ou suppression dans les prévisions validées.
- Si non, affichage des prévisions puis exécution de la tâche de validation des prévisions par
l’acteur ‘CD’.
- Si cet acteur est un chef de département non rattaché à D *E (Sous direction d’exploitation),
il communique les prévisions validées à l’acteur (F) pour consultation et à l’acteur
département Approvisionnement (A) pour prise en compte dans son budget achat A et
pour exploitation.
- Si non, il communique les prévisions validées à l’acteur (D *E) qui va procéder à une
troisième validation par tableau de consommations quantitatives.
- Si l’acteur (D*E) constate des anomalies il les communique à l’acteur ‘chef département A’
(CDA).
- l’acteur (CDA) effectue un déverrouillage et avise l’acteur ‘CS’ pour consulter, saisir et
enregistrer à nouveau les prévisions.
- Si non, l’acteur (D*E) transmet les prévisions validées à l’acteur (F) pour consultation et à
l’acteur (A) pour prise en compte dans son budget achat A et pour exploitation.
- L’acteur ‘Service AG’ (SAG) et après la validation des prévisions effectuée au niveau de
l’acteur ‘chef de département’ et celle effectuée au niveau de l’acteur (D *E), affiche les
prévisions puis il procède à la validation des entrées quantitatives, en suite il affiche
des articles quantifiés sur le tableau.
- Si l’acteur (SAG) constate des anomalies et après avoir obtenu le déverrouillage auprès de
l’acteur ‘Service AA’ (SAA), il effectue les modifications ou suppressions dans les
prévisions validées.
 - Si non, l’acteur (SAG) communique les prévisions à l’acteur (SAA) qui va procéder à la
valorisation et au calcul des prévisions consolidées d’achat et de consommation, puis à
l’affichage et la vérification des entrées établies. En fin la procédure d’approbation du
budget est entamée.

4.2.2 Diagramme d'activités du Budget PA et PMT élaboré par le département

Finances (F)
 Description du processus (F) :
- L’acteur (F) élabore puis transmet ses prévisions PA et PMT quantitatives de missions à
l’acteur (M). Ce dernier établie l’état des missions détaillé.
- L’acteur ( F) élabore aussi les prévisions quantitatives PA et PMT de consommation de
fournitures, en suite ; il les transmet à l’acteur (M) afin de compléter le budget achat M.
- L’acteur (F) élabore ses prévisions valorisées PA et PMT de prestations de services.
- Après la réception des prévisions valorisées de toutes les structures de l’unité, en se
basant sur le plan de production et consultant les soldes des comptes comptables de
dettes et créances par nature de dépenses , l’acteur (F) exécute la tâche de consolidation
des prévisions valorisées PA et PMT des produits pour élaborer les prévisions de
trésorerie de l’unité.
- Dès la réception des prestations inter-unités et des plans d’investissement,
d’approvisionnement et de consommations valorisées (A) et (M), l’acteur (F) élabore les
prévisions valorisées PA et PMT relatives aux Prévisions prestation inter-unité, aux

impôts et taxes, aux assurances, frais bancaires et aux valorisations des prévisions de
GN autoconsommé et à la dotation aux amortissements en se basant sur le listing des
véhicules légers et utilitaires réel, sur la Patrimoine à assurer et sur le prix GN
autoconsommé retenu comme norme.
Une tâche de consolidation des prévisions valorisées des charges et des produits est exécutée
par l’acteur (F) à l’issu de cette dernière.
4.2.3 Diagramme d'activités du processus de procédure de validation des

prévisions de consommations quantitatives pour les articles non gérées en
stocks (M) du plan annuel et PMT

 Description du processus de validation des prévisions des articles non gérés en stock M:
- Dès la réception des prévisions, l’acteur ‘Chefs de services’ entame la procédure de
saisie des prévisions et des réalisations de consommations des articles non gérés en
stock M.
- Après affichage sur tableau des articles quantifiés (mouvementés), vient la première
validation des prévisions enregistrées.
- En cas d’anomalies, un déverrouillage par l’acteur ‘chef de département de
rattachement ‘ est indispensable pour modifier ou supprimer une prévision validée.
- Après la 1ère validation, les prévisions validées sont affichées par service dans un
tableau au niveau de l’acteur ‘chef de département de rattachement’.
- Ce dernier effectue une deuxième validation par tableau des prévisions de
consommations quantitatives.
- A l’issu de cette validation, les prévisions seront exploitées par l’acteur ‘M’,
consultées par l’acteur ‘F’ et affichées au niveau de l’acteur ‘D *S/D*E’.
- En fin, l’acteur ‘D*S/D*E’ procède à la validation des prévisions par tableau. Ces
prévisions validées seront exploitées par l’acteur ‘M’ et consultées par ‘F’.

5. Modélisation par Workflow
5.1 Eléments de diagrammes de processus Workflow
Un business process diagram contient différents éléments, lesquels représentent

différentes étapes du processus comme définit ci-après :
Forme Rappel sur la description
Les événements sont représentés par des cercles et décrivent quelque

chose qui se passe. Les événements indispensables au bon
fonctionnement du diagramme sont l’événement de départ et
l’événement final.
Task Les activités (task) sont représentées par un rectangle aux coins
arrondis et indiquent la tâche qui doit être effectuée.
Les passerelles, représentées par des losanges, indiquent un point de

décision. Elles doivent être ouvertes avant une décision et refermées
sitôt que les différents chemins se rejoignent. Les passerelles (gateway)
sont utilisées lorsque deux directions différentes peuvent être prises à
choix. Au contraire, la passerelle (fork/join) est utilisée lorsque deux
processus différents sont effectués en même temps.
Ces différents éléments sont tous reliés entre eux grâce à trois
différents types d’objets de connexion. Les flux de séquence (sequence
flow) sont représentés par une flèche pleine et une ligne solide. Ils
indiquent les suites d’événements ou d’activités.
Les flux de message (message flow) quand à eux sont représentés avec
une flèche vide et une ligne traitillée. Ils indiquent quel message circule
entre deux participants.
Les associations consistent uniquement en une ligne traitillée utilisée
pour associer un fichier ou un texte à un objet.
Pool
Les swimlanes permettent d’organiser les tâches à l’intérieur de
différentes colonnes représentant chacune un acteur
Les artefacts (artifacts) permettent au développeur du diagramme

d’apporter des informations complémentaires afin de le rendre plus
compréhensible. Les objets de données (data object) sont utilisés afin
d’indiquer au lecteur quel donnée est nécessaire ou est produite dans
Data une activité.

5.2 Modélisation des diagrammes de processus Workflow
Suite aux concepts cités dans le chapitre 2, nous allons modéliser vingt processus
workflow. Parmi eux seize sont relatifs aux processus de l’élaboration des prévisions
budgétaires effectués par les différents départements et directions et les autres quatre
diagrammes concernent les différents processus de validation.
Pour cela nous utiliserons les business process diagram (diagrammes des
processus métiers) qui sont très comparables aux diagrammes d’activités UML
(fonctionnement et représentation).
 Pour ne pas rendre nos business process diagrams complexes, nous allons
utiliser pour chaque acteur un nœud de fin de processus. Mais dans la
validation nous devons utiliser un et un seul nœud.

5.2.1 Diagramme de processus métier des prévisions budgétaires PA et PMT

élaborées par le département Production (P)
 Description du processus (P) : Voir la description donnée en section 4.2.1.

5.2.2 Diagramme de processus métier des prévisions budgétaires PA et PMT

élaborées par le département Finances (F)
 Description du processus (F) : Voir la description présentée dans la section 4.2.2.

5.2.3 Diagramme de processus métier relatif à la validation des prévisions de

consommations quantitatives PA et PMT des articles non gérés en stock de
département des moyens généraux (M)
 Description du processus de validation des prévisions des articles non gérés en stock M:
- Dès la réception des prévisions, l’acteur ‘Chefs de services’ entame la procédure de
saisie des prévisions et des réalisations de consommations des articles non gérés en
stock M.
- Après affichage sur tableau des articles quantifiés (mouvementés), vient la première
validation des prévisions enregistrées.
- En cas d’anomalies, un déverrouillage par l’acteur ‘chef de département de
rattachement ‘ est indispensable pour modifier ou supprimer une prévision validée.

- Après la 1ère validation, les prévisions validées sont affichées par service dans un
tableau au niveau de l’acteur ‘chef de département de rattachement’.
- Ce dernier effectue une deuxième validation par tableau des prévisions de
consommations quantitatives.
- A l’issu de cette validation, les prévisions seront exploitées par l’acteur ‘M’,
consultées par l’acteur ‘F’ et affichées au niveau de l’acteur ‘D*S/D*E’.
- En fin, l’acteur ‘D*S/D*E’ procède à la validation des prévisions par tableau. Ces
prévisions validées seront exploitées par l’acteur ‘M’ et consultées par ‘F’.
5.2.4 Diagramme de processus métier relatif à l’élaboration des prévisions

budgétaires PA et PMT réalisées par le département Approvisionnement (A).

 Description du processus (A) :

- L’acteur département Approvisionnement (A) et après réception des prévisions de
consommation relatives aux départements P,G,T et I, élabore les prévisions de
fonctionnement et les prévisions de prestations de service(missions). Il les transmet
à l’acteur département Moyens Généraux (M).
- Ce dernier complète le budget achat M et établie l’état des missions détaillé.
- Suivant la politique de réapprovisionnement et selon le stock existant, l’acteur (A)
élabore les prévisions valorisées en exploitant la table des prix.
- Dès réception des prévisions valorisées de l’acteur (A), l’acteur (F) les prend en
compte dans la consolidation des charges si il s’agit des dotations aux provisions
pour dépréciation des stocks gérés par A. Si non , il les prend en compte dans la
consolidation des charges et dans le budget trésorerie.

budgétaires PA et PMT réalisées par le département Système d’information
et de Gestion (SIG).

 Description du processus (SIG) :

- Dès réception des prévisions quantitatives des consommations de fournitures et
consommables informatiques, l’acteur département Système d’Information et de
Gestion (SIS) élabore :
- les prévisions consolidées de consommations et consommables informatiques.
- les prévisions de missions qui vont être transmises à l’acteur (M) pour établir l’état
des missions professionnelles détaillé.
- les prévisions valorisées de prestations de services. Il les transmet à l’acteur (F)
pour les prendre en compte dans le budget de trésorerie.
- les prévisions de consommation de matières et fourniture.
- L’acteur (M) et après réception de l’acteur (SIG) des prévisions de consommations
consolidées gérées en stock exécute la tâche de la valorisation. Dans le cas de
prévisions de consommation consolidées non gérées en stock ou de prévisions de
consommations pour fonctionnement, il complète le budget achat M.

budgétaires PA et PMT réalisées par le département Administration et
Social (S).

 Description du processus (S) :

- Dès réception du plan des effectifs et des besoins organigrammes, l’acteur
département Administration et Social (S) commence à :
- Elaborer les prévisions quantitatives des fournitures non gérées en stock et non
régies par une norme. Ces prévisions vont être transmises à l’acteur (M) afin de
compléter son budget achat.
- Valoriser les prévisions des salaires, charges patronales, AFC, STC et gratification
en appliquant la norme de la masse salariale RHU/AVAL.
- Valorise les prévisions de prestations de service, outillage médical et produits
pharmaceutiques.
- Il transmet les prévisions valorisées des salaires et charges et les prévisions
médicales valorisées à l’acteur (F) pour les prendre en compte respectivement dans
le budget trésorerie et le budget des charges.
- Comme il transmet à l’acteur (M) les prévisions relatives aux missions
professionnelles afin d’établir l’état détaillé des missions professionnelles.
- En parallèle, il envoie à l’acteur (M) les prévisions quantitatives de transport scolaire
et universitaire et celles des loyers et charges locatives sous forme de listes
nominatives.

budgétaires réalisées par le Service Relations du Travail (RT).

 Description du processus (RT) :

- Dès réception de la directive cadre, l’acteur service Relation de Travail (RT) élabore
puis transmet à l’acteur (M) :
- les prévisions quantitatives de consommation de fournitures non gérées en stock et
non régies par une norme afin de compléter le budget achat M.
- les prévisions de missions par destinations pour établir l’état détaillé des missions.

budgétaires PA et PMT réalisées par le département Moyens Généraux (M).

 Description du processus (M) :

- Dès réception de la note et de la directive cadre, l’acteur (M) élabore et valorise ses
propres prévisions.
- Après réception des prévisions quantitatives de consommation de toutes les
structures, l’acteur (M) exécute la tâche de valorisation des ces prévisions en
appliquant les normes de consommation en quantité et en exploitant le tableau des
prix.
- En respectant les normes afférents aux prestations de services il élabore :
- les prévisions consolidées de missions des structures, puis il les transmet à l’acteur
(F) pour l’établissement d’un état détaillé de missions et de formations.
- Elaborer les prévisions de prestations de services et de dotations aux provisions
pour dépréciation des stock. Ces prévisions seront transmises à l’acteur (F) afin de
les prendre en compte dans la consolidation des charges et prestations
contractuelles.
- L’achèvement des deux premières tâches déclenche la tâche de la consolidation des
prévisions par l’acteur (M) en se basant sur la politique de gestion des stocks. Ces
prévisions seront transmises à l’acteur (F) pour les prendre en compte dans la
consolidation des charges et dans le budget trésorerie.
- Sous forme de listes du nombre prévisionnel d’agents, l’acteur (M) transmet à
l’acteur ‘DAG/MOG’ les prévisions quantitatives des loyers et charges locatives et
de transport scolaire et universitaire.
- En exploitant le tableau des prix, l’acteur ‘DAG/MOG’ valorise puis transmet ces
prévisions reçues à l’acteur ‘DAG/FG’ qui va les transmettre à son tour à l’acteur
‘F.UNITES’.


budgétaires PA et PMT réalisées par le département Ressources Humaines (R).
 Description du processus (R) :
- Dès réception de la note et de la directive cadre, des besoins organigrammes et du

plan des départs en retraite, l’acteur (R) élabore les prévisions quantitatives de
formation selon le plan de formation. Il les transmet à l’acteur (M) pour compléter
son budget achat.
- En exploitant le tableau des prix unitaires de formations et séminaires, l’acteur (R)
valorise les prévisions de prestations de formation et des taxes. Ces prévisions
valorisées sont transmises à l’acteur (F) afin de les prendre en compte dans le budget
trésorerie et/ou charges inter-unité.
- l’acteur (R) élabore les prévisions de prestations de services. Il transmet les
prévisions de missions professionnelles et les prévisions de missions pour formation
à l’acteur (M). Ce dernier et selon le cas, il établie un état détaillé de missions.


budgétaires PA et PMT réalisées par le département Passation des
Marchés (PM).
 Description du processus (PM) :
- Dès réception de la note et de la directive cadre et du plan de passation des marchés

par structure, l’acteur (PM) élabore :
- les prévisions quantitatives de consommation de fournitures. Il les transmet à
l’acteur (M) pour compléter son budget achat.
- les prévisions valorisées de prestations de services. formation et des taxes. Ces
prévisions valorisées sont transmises à l’acteur (F) afin de les prendre en compte
dans le budget trésorerie.
- les prévisions de missions qui seront transmises par la suite à l’acteur (M). Ce
dernier établie un état détaillé de missions.

- les prévisions consolidées de recettes liées aux retraits des cahiers de charges. Puis
il les transmet à l’acteur (F) pour les prendre en compte dans les prévisions de
produits d'exploitation.

budgétaires réalisées par l’Assistant Sûreté Interne (ASI).
 Description du processus (ASI) : idem que la description précédente du processus (PM)

sauf que et en plus de la note et la directive cadre, l’évènement déclencheur cette fois ci
est la réception des prévisions relatives au nombre de personnel ouvrant droit à l’accès
aux différentes zones.


budgétaires réalisées par le Conseil Syndical.
 Description du processus (Conseil Syndical) :
- Dès réception de la directive cadre, l’acteur Conseil Syndical élabore puis transmet à
l’acteur (M) :
- les prévisions quantitatives de consommation de fournitures non gérées en stock et
non régies par une norme afin de compléter le budget achat M et de valoriser les
consommations.
- les prévisions de missions par destinations pour établir l’état détaillé des missions.


budgétaires PA et PMT réalisées par le département Maintenance (G).
 Description du processus (G) :
Dès la réception d’une note accompagnée de la directive cadre, du plan de

maintenance et du plan d’investissement, le département Maintenance (G) commence à
élaborer en parallèle les prévisions PA et PMT de consommations des matières et
fournitures tout en respectant les paramètres et normes en vigueur, les prévisions
quantitatives PA et PMT de missions et les prévisions valorisées PA et PMT de prestation de
services.
Une fois l’élaboration des prévisions est terminée, cet acteur (G) transmet à l’acteur
département de Finance (F) ses besoin en matière de prestation de services pour que ce
dernier les prenne en charge dans l’élaboration du budget de trésorerie. Il transmet aussi ses

prévisions de missions à l’acteur département Moyens Généraux (M) qui va à son tour
établir un état des missions détaillé en tenant en compte les prévisions reçues.
Si il s’agit de prévisions de consommation non liée à la fonction maintenance,
l’acteur (G) transmet ses prévisions à l’acteur (M) afin de lui permettre de compléter son
budget d’achat M, si non il transmet les prévision au chef de service. Ce dernier a pour rôle
la saisie et l’enregistrement des prévisions. Un test est effectué à son niveau, dans le cas
d’anomalies il les communique à l’acteur (G) pour correction et actualisation. Une fois la
correction est faite et dans l’absence d’anomalies, une tâche de validation des prévisions est
exécutée par l’acteur ‘Chef de Service’. Dès que cette première validation est terminée, les
prévisions validées sont affichées au niveau de l’acteur ‘chef de département’. Ce dernier
effectue une deuxième validation. Si cet acteur est un chef de département non rattaché à
D*E, il communique les prévisions validées à l’acteur (F) pour consultation et à l’acteur (A)
pour prise en compte dans son budget achat A et pour exploitation. Si non (c à d. chef
département rattaché à D*E), il communique les prévisions validées à l’acteur ‘D *E’ qui va
procéder à une troisième validation par tableau de consommations quantitatives. Si il
constate des anomalies il les communique à l’acteur ‘chef de service’ pour consulter, saisir
et enregistrer à nouveau les prévisions. Si non (c à d pas d’anomalies constatées par l’acteur
‘D*E’), les prévisions validées vont être transmises à l’acteur (F) pour consultation et à
l’acteur (A) pour prise en compte dans son budget achat A et pour exploitation.

budgétaires réalisées par la Direction de l’unité, D*E et D*S.
 Description du processus (D*E et D*S) : Ce processus est le même que le processus (RT)
avec l’acteur (D*E et D*S) à la place de (RT).


budgétaires PA et PMT réalisées par le département Technique (T).
 Description du processus (T) :

Dès la réception d’une note accompagnée de la directive cadre et le planning des
visites, le département Technique (T) commence à élaborer en parallèle les prévisions
quantitatives PA et PMT, les prévisions de prestation de services tout en respectant les
normes réglementaires et les prévisions de missions.
Une fois l’élaboration des prévisions est terminée, l’ acteur (T) transmet à l’acteur
(F) ses besoin en matière de prestation de services pour que ce dernier les intègre dans le
budget de trésorerie. Il transmet aussi ses prévisions de missions à l’acteur (M) qui va établir
un état détaillé des missions professionnelles en tenant en compte les prévisions reçues.
Si il s’agit de prévisions de consommation pour le fonctionnement, l’acteur (T) transmet ses
prévisions régies par norme et gérées en stock à l’acteur (M) afin de lui permettre de
compléter son budget achat M, si non il transmet les prévision de matières et fournitures
gérées et non gérées en stock au chef de service. Ce dernier a pour rôle la saisie et

l’enregistrement des prévisions. Un test est effectué à son niveau, dans le cas d’anomalies il
les communique à l’acteur (T) pour correction et actualisation. Une fois la correction est faite
et dans l’absence d’anomalies, une tâche de validation des prévisions est exécutée par
l’acteur ‘Chef de Service’. Dès que cette première validation est terminée, les prévisions
validées sont affichées au niveau de l’acteur ‘chef de département’. Ce dernier effectue une
deuxième validation. Si cet acteur est un chef de département non rattaché à D *E, il
communique les prévisions validées à l’acteur (F) pour consultation et à l’acteur (A) pour
prise en compte dans son budget achat A et pour exploitation. Si non, il communique les
prévisions validées à l’acteur ‘D*E’ qui va procéder à une troisième validation par tableau de
consommations quantitatives. Si il constate des anomalies il les communique à l’acteur
‘chef de service’ pour consulter, saisir et enregistrer à nouveau les prévisions. Si non, les
prévisions validées vont être transmises à l’acteur (F) pour consultation et à l’acteur (A) pour
prise en compte dans son budget achat A et pour exploitation.

budgétaires PA et PMT réalisées par le département Sécurité Industrielle (I).

 Description du processus (I) :

Ce processus est similaire que le processus (T) sauf que:
- l’évènement déclencheur est composé de la note accompagnée de le directive cadre et
du plan HSE.
- l’acteur principal est le département Sécurité industrielle (I) au lieu de l’acteur (T).

budgétaires PA et PMT réalisées par le département Travaux Neufs (W).
 Description du processus (W) :

Ce processus est similaire que le processus (T) sauf que:
- l’évènement déclencheur est composé de la note accompagnée de le directive cadre et
des programmes d’investissements.
- l’acteur principal est le département Travaux neufs (I) au lieu de l’acteur (T).
- les documents exploités pour l’élaboration des prévisions quantitatives et des
prévisions de prestations de services sont Planning des arrêts de maintenance , listing
des investissements et les conventions.

5.2.18 Diagramme de processus métier relatif à la validation des prévisions des

stocks, d’achats et consommations des articles gérés en stock (A) du plan
annuel et PMT.
 Description du processus de validation des prévisions des articles gérés en stock A:

- Dès la réception des prévisions, l’acteur ‘Chef de service (A)’ entame la procédure de
consultation, de saisie et d’enregistrement des prévisions.
- En cas d’anomalies, l’acteur ‘Chef de service (A)’ avise l’acteur (A) pour une éventuelle
correction et actualisation. Une fois cette correction est faite et dans l’absence
d’anomalies, l’acteur ‘Chef de service (A)’ exécute la tâche de validation.

- L’acteur ‘chef de département de rattachement’ consulte les prévisions validées. S’il

constate des anomalies il effectue un déverrouillage afin de permettre à l’acteur ‘chef de
service’ de procéder à la modification ou la suppression dans les prévisions validées.
Dans l’absence d’anomalies et après affichage des prévisions validées, l’acteur ‘chef de
département de rattachement’ valide les prévisions.
- Si cet acteur est un chef de département non rattaché à D*E, il communique les prévisions
validées à l’acteur (F) pour consultation et à l’acteur (A) pour prise en compte dans son
budget achat A et pour exploitation. Si non, il communique les prévisions validées à
l’acteur ‘D*E’ qui va procéder à une troisième validation par tableau de consommations
quantitatives. Si il constate des anomalies il avise l’acteur ‘chef de département (A)’ pour
effectuer le déverrouillage afin de permettre à l’acteur ‘chef de service’ de consulter, saisir
et enregistrer à nouveau les prévisions. Si non, les prévisions validées vont être
transmises à l’acteur (F) pour consultation et à l’acteur (A) pour prise en compte dans son
budget achat A et pour exploitation.
- Après la deuxième validation des prévisions et la troisième validation par tableau de
consommations quantitatives effectuées respectivement par les acteurs ‘chef de
département de rattachement’ et ‘D*E’, un affichage des prévisions de consommations
gérées en stock et du tableau des prévisions de consommations quantitatives est effectué
au niveau de l’acteur ‘Service AG’ qui va procéder à la validation des entrées
quantitatives, puis à l’affichage des articles quantifiés sur le tableau et en fin à une
modification ou suppression dans les prévisions validées après exécution de
déverrouillage par l’acteur ‘Service AA’.
- Ce dernier et après avoir reçu les prévisions quantitatives validées et actualisées de
l’acteur ‘Service AG’ passe à la valorisation et au calcul des prévisions consolidées.
Après affichage des entrées établies, un test de vérification est effectué par cet acteur. Si
ces entrées ne sont pas approuvées, il les communique à l’arteur (A) pour révision. Ce
dernier transmet les entrées révisées à l’acteur ‘structure concernée’. Cet acteur modifie
les prévisions de consommation puis envoie les prévisions modifiées à l’acteur ‘chef
département (A)’. Ce dernier et après déverrouillage des tableaux de consommations
quantitatives, puis affichage des articles valorisés transmet ces prévisions modifiées à
l’acteur ‘Service AA’. Une validation des prévisions enregistrées modifiées/approuvées
est effectuée par cet acteur. Qui va en suite communiquer les prévisions validées à
l’acteur ‘chef département (A)’ pour une autre validation. L’acteur ‘chef département (A)’
et dans le cas d’anomalies opère une modification ou suppression dans les prévisions
validées après déverrouillage effectué par l’acteur ‘D*S’. Dans l’absence d’anomalies,
l’acteur (A) envoie les prévisions validées à l’acteur ‘D*S’ pour validation des tableaux
quantitatifs et valorisés. En fin, l’acteur ‘D*S’ communique ces tableaux à l’acteur (F) qui
va les exploiter.

5.2.19 Diagramme de processus métier relatif à la validation des prévisions des

stocks, d’achats et consommations des articles non gérés en stock (A) du
plan annuel et PMT.
 Description du processus de validation des prévisions des articles non gérés en stock A :
Idem que le processus précédent, sauf que l’acteur ‘Service AG’ n’intervient
pas cette fois, et que l’acteur ‘Service AA’ a des tâches en plus, telle que l’affichage des
prévisions des consommations non gérées en stock A, la validation des prévisions
quantitatives et consolidées d'achat des articles non gérés en stock A et la
modification/suppression dans les prévisions validées.

5.2.20 Diagramme de processus métier relatif à la validation des prévisions

consolidées d’achats et consommations pour les articles non gérés en stock
(M) du plan annuel et PMT.
 Description du processus de validation des prévisions consolidées de consommations

des articles non gérés en stock M:
- Dès la réception des prévisions de consommations des structures, l’acteur (M)
entame la procédure de valorisation des prévisions quantitatives et d'achets consolidées
en exploitant la table des prix. Puis il exécute une tâche de vérification des prévisions

établies. Dans le cas de non approbation des prévisions, il les transmet à l’acteur
‘structure concernée’.
- Après une modification des prévisions et acceptation des modification par
l’acteur ‘structure concernée’, un déverrouillage des tableaux de consommations
quantitatives M et des tableaux des départements concernés, puis un affichage des
entrées non approuvées des articles valorisés sont effectués par l’acteur ‘chef de
département (M)’.
- L’acteur ‘chef de service (M) et après approbations des prévisions établies ou
affichage des entrées non approuvées des articles valorisés valide les prévisions
enregistrées. Dans le cas d’anomalies il procède à une modification ou suppression dans
les prévisions validées après un déverrouillage effectué par l’acteur ‘chef de département
(M)’. Dans l’absence d’anomalies ou après modification, une validation des prévisions est
effectué par l’acteur ‘chef de département (M)’. Ce dernier et en cas d’anomalies , effectue
lui-même une modification ou suppression dans les prévisions validées après un
déverrouillage effectué par l’acteur après un déverrouillage effectué par l’acteur ‘D*S’.
- L’acteur D*E et après le résultat du test effectué par l’acteur ‘chef de
département (M)’ exécute une tâche de validation des tableaux des prévisions
consolidées d’achats et consommations pour les articles non gérés en stock (M), en suite
il communique les tableaux des prévisions validés à l’acteur ‘structure concernée’ pour
prise en charge dans le budget d’achat et à l’acteur (F) pour exploitation du tableau des
prévisions consolidées d’achats et consommations pour les articles non gérés en stock
(M).

Chapitre 5
Validation des diagrammes de

processus WorkFlow modélisés
Chapitre V – Validation des diagrammes de processus Workflow 79
5.1 Introduction
Cette étape consiste à l’élaboration des fichiers BPEL correspondant aux
diagrammes des processus métiers modélisés.
Pour cela nous avons utilisé le logiciel MagicDraw, qui rend possible l’exportation
de diagrammes des processus métiers vers du BPEL, il suffit d’utiliser la fonction « exporter
» puis « BPEL » dans l’onglet fichier pour qu’un fichier BPEL soit créé. Bien sûr cela n’est
effectuable uniquement si le diagramme ne contient aucune erreur. Dans le cas contraire
l’exportation n’est pas possible et le programme indiquera le type d’erreur soulevée.
Le fichier BPEL ainsi créé se présente sous la forme d’un fichier XML comme nous
l’avons vue dans le chapitre 3:
5.2 Génération des fichiers BPEL de validation

Nous allons tout d’abord présenter à titre d’exemple quelques figures illustrant
les différentes étapes à suivre pour modéliser un processus workflow sous l’éditeur
MagicDraw.
Figure 5.1- Création d’un nouveau projet nommé BPD_Finances à partir de la page d’accueil MagicDraw

Figure 5.2- Sélection d’un Star Event du menu principal du logiciel MagicDraw
Figure 5.3- Création d’un star Event avec un nœud fork/join et des nœuds d’activités

Figure 5.4- Création d’un processus métier relatif à l’élaboration des prévisions budgétaires des finances
Après avoir crée le modèle de processus métier sous l’éditeur MagicDraw, nous
passons à l’étape de sa validation en exécutant comme nous avons vu dans la section 5.1 la
fonction « exporter » puis « BPEL » dans l’onglet fichier et en fin nous obtiendrons les fichier
BPEL correspondants aux différents processus métiers que nous allons présenter ci dessous.

5.2.1 Fichier BPEL du diagramme de processus métier des prévisions

budgétaires élaborées par le département Production (P)
<xml version='1.0' encoding='UTF-8'?>

<process xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/">
<partnerLinks>
<partnerLink myRole="dfltMyRole" name="dfltName" partnerLinkType="dfltPartnerLinkType"
partnerRole="dfltPartnerRole"></partnerLink></partnerLinks>
<partners>
<partner name="dfltName"></partner>
<partnerLink name="dfltName"></partnerLink></partners>
<variables>
<variable messageType="dfltMessageType" name="dfltName"></variable></variables>
<sequence>
<receive createInstance="yes" name="plan de production" operation="dfltOperation" partner=""
partnerLink="dfltPartnerLink" portType="dfltPortType" variable=""></receive>
<Flow name="">
<sequence>
<empty name="Elaboration des prévisions de prestations de services PA et PMT "></empty>
<empty name="Transmission des prévisions de prestation de services "></empty>
<empty name="Intégration dans le budget trésorerie"></empty>
</sequence>
<sequence>
<empty name="Elaboration des prévisions de missions PA et PMT "></empty>
<empty name="Transmission des prévisions des missions "></empty>
<empty name="Etablissement d'état de missions professionnelles détaillé "></empty>
</sequence>
<sequence>
<empty name="Elaboration des prévisions de consommation PA et PMT "></empty>
<switch name="">
<case condition="Non quantitative">
<empty name="Transmission des prévisions des énergies "></empty>
<empty name="Intégration dans le budget trésorerie"></empty>
</case>
<otherwise>
<switch name="">
<case condition="Non lié à la production">
<empty name="Transmission des prévisions"></empty>
<empty name="Compléter le budget Achat M "></empty>
</case>
<otherwise>
<empty name="Transmission des prévisions de consommable production gérées et
non gérées en stock "> </empty>
<empty name="Consultation, saisie et enregistrement des prévisions "></empty>
<switch name="">
<case condition="Cas d’anomalies">
<empty name="Correction et Actualisation "></empty>
</case>

</switch>
<empty name="Validation des prévisions "></empty>
<empty name="Consultation des prévisions "></empty>
<switch name="">
<empty name="Déverrouillage"></empty>
<empty name="Modification ou suppression dans les prévisions validées">
</empty>
</case>
</switch>
<empty name="Affichage des prévisions validées"></empty>
<empty name="Validation des prévisions "></empty>
<sequence>
<switch name="">
<case condition="Chef de département rattaché à D*E">
<empty name="Affichage des prévisions validées"></empty>
<empty name="Validation par tableau de consommations quantitatives">
</empty>
<sequence>
<empty name="Affichage des prévisions des consommations gérées en
stock et du tableau des prévisions de consommations
quantitatives"></empty>
<empty name="Validation des entrées quantitatives"></empty>
<empty name="Affichage des articles quantifiés sur le tableau"></empty>
<switch name="">
<empty name="Déverrouillage"></empty>
<empty name="Modification ou suppression dans les prévisions
validées">
</empty>
</case>
</switch>
<empty name="valorisation et calcul des prévisions consolidées d'achat et
de consommation ">
</empty>
<empty name="Affichage et vérification des entrées établies "></empty>
</sequence>
<sequence>
<switch name="">
<case condition=" Cas d’anomalies ">
<empty name=" Déverrouillage "></empty>
<empty name=" Consultation, saisie et enregistrement des
prévisions ">
</empty>
</case>
<otherwise>
<switch name="">
<case condition="Pour finance">
<empty name="Consultation des prévisions validées">
</empty>
</case>

<otherwise>
<empty name="Prise en compte dans le budget Achat A et
exploitation des prévisions validées ">
</empty>
</otherwise>
</switch>
</otherwise>
</switch>
</sequence>
</case>
<otherwise>
<switch name="">
<case condition="Pour finance">
<empty name="Consultation des prévisions validées"></empty>
</case>
<otherwise>
<empty name="Prise en compte dans le budget Achat A et exploitation
des prévisions validées ">
</empty>
</otherwise>
</switch>
</otherwise>
</switch>
</sequence>
<sequence>
<empty name="Affichage des prévisions des consommations gérées en stock et du
tableau des prévisions de consommations quantitatives">
</empty>
<empty name="Validation des entrées quantitatives"></empty>
<empty name="Affichage des articles quantifié s sur le tableau "></empty>
<switch name="">
<empty name=" Déverrouillage "></empty>
<empty name="Modification ou suppression dans les prévisions validées">
</empty>
</case>
</switch>
<empty name="valorisation et calcul des prévisions consolidées d'achat et de
consommation "></empty>
<empty name="Affichage et vérification des entrées établies "></empty>
</sequence>
</otherwise>
</switch>
</otherwise>
</switch>
</sequence>
</flow>
</process>

5.2.2 Fichier BPEL du diagramme de processus métier des prévisions

budgétaires élaborées par le département Finance (F)
<partnerLinks>
<partners>
<variables>
<sequence>
<receive>
<receive createInstance="yes" name="Fichier et Plan d’investissement" operation="dfltOperation"
partner="" partnerLink="dfltPartnerLink" portType="dfltPortType" variable=""></receive>
<receive createInstance="yes" name="Plan de production" operation="dfltOperation" partner=""
<receive createInstance="yes" name="Plan d’approvisionnement" operation="dfltOperation" partner=""
<receive createInstance="yes" name="Plan de consommations valorisées (A & M)"
operation="dfltOperation" partner="" partnerLink="dfltPartnerLink" portType="dfltPortType"
variable=""></receive>
<receive createInstance="yes" name="Prestations inter-unité" operation="dfltOperation" partner=""
<receive createInstance="yes" name="Prévisions valorisées de toutes les structures"
<receive createInstance="yes" name="Soldes des comptes comptables de dettes et créances par nature
de dépenses" operation="dfltOperation" partner="" partnerLink="dfltPartnerLink"
portType="dfltPortType" variable=""></receive>
<receive createInstance="yes" name="Patrimoine à assurer" operation="dfltOperation" partner=""
<receive createInstance="yes" name="Listing des vehicules légers et utilitaires réels"
<receive createInstance="yes" name="Paiement pour compte" operation="dfltOperation" partner=""
<receive createInstance="yes" name="Prix GN autoconsommé retenu comme norme"
</receive>
<Flow name= "">
<sequence>
<empty name="eElaboration des prévisions quantitatives de missions PA et PMT"></empty>
<empty name="Transmission des prévisions des missions"></empty>
<empty name="Etablissement de l’état de missions détaillé"></empty>
</sequence>
<sequence>

<empty name="Elaboration des prévisions quantitatives PA et PMT de consommation de fournitures

"> </empty>
<empty name="Transmission des prévisions de consommation de fournitures "></empty>
<empty name=" Compléter le budget achat M"></empty>
</sequence>
<sequence>
<empty name="Elaboration des prévisions valorisées PA et PMT de prestations de services pour
(F)">
</empty>
<empty name="Elaboration des prévisions de trésorerie PA et PMT"></empty>
</sequence>
<sequence>
<empty name="Consolidation des prévisions valorisées des produits (Unité) PA et PMT"></empty>
<empty name="Elaboration des prévisions de trésorerie (Unité) PA et PMT"></empty>
</sequence>
<sequence>
<empty name="Elaboration des prévisions valorisées PA et PMT de dotation aux
amortissements">
</empty>
<empty name="Elaboration des prévisions valorisées PA et PMT de prestations inter-unité ">
</empty>
<empty name="Elaboration des prévisions valorisées PA et PMT des Impôts et taxes, Assurances,
frais bancaires">
</empty>
<empty name="Valorisations des prévisions de GN autoconsommé"></empty>
<empty name="Consolidation des prévisions valorisées avec les prévisions valorisées des charges
(Unité) PA et PMT">
</empty>
</sequence>
</Flow name>
</sequence>
</process>
5.2.3 Fichier BPEL du diagramme de processus métier relatif à la validation

des prévisions de consommations quantitatives des articles non gérés
en stock de département des moyens généraux (M)
<partnerLinks>
<partners>
<variables>
<sequence>
<receive createInstance="yes" name="Reception des prévisions et des réalisations de consommations
des articles non gérés en stock M" operation="dfltOperation" partner="" partnerLink="dfltPartnerLink"
portType="dfltPortType" variable=""></receive>

<Flow name="">
<empty name=" Saisie des prévisions et des réalisations de consommations des articles non gérés
en stock M">
</empty>
<empty name="Affichage des articles quantifiés "></empty>
<empty name="Validation des prévisions enregistrées"></empty>
<switch name="">
<empty name="Dévrrrouillage "></empty>
<empty name="Modification /suppression dans les prévisions validées"></empty>
</case>
</switch>
<empty name="Affichage par tableau des prévisions validées "></empty>
<empty name="Validation par tableau de consommations quantitatives"></empty>
switch name="">
<empty name="Dévrrrouillage "></empty>
<empty name="Modification /suppression dans les prévisions validées"></empty>
</case>
</switch>
switch name="">
<case condition=" Département M ">
<empty name="Exploitation des prévisions"></empty>
</case>
<otherwise>
<switch name="">
<case condition="Département F">
<empty name="Consultation des prévisions"></empty>
</case>
<otherwise>
<empty name="Affichage des prévisions annuelles par tableau "></empty>
<empty name="Validation par tableau des prévisions de consommations
quantitatives">
</empty>
<sequence>
<empty name="Consultation des prévisions"></empty>
</Sequence>
<sequence>
<empty name=" Exploitation des prévisions "></empty>
</Sequence>
</otherwise>
</switch>
</otherwise>
</switch>
</Flow>
</Sequence>
</process>

Chapitre 6
Architecture des processus métiers

et représentation relationnelle du
modèle statique
Chapitre VI - Architecture des processus métiers et représentation relationnelle 88
1. Introduction
Dans ce chapitre nous allons présenter les vues partielles des architectures métiers
du système étudié enrichies d’une description textuelle de chaque architecture. En suite,
nous allons entamer la procédure de la représentation relationnelle du modèle statique que
nous avons conçu dans le chapitre IV.
2. Architecture des processus métiers
2.1. Architecture du processus métier de département Production (P)

- Description de l’architecture (P):
Cette architecture représente le processus métier relatif à l’élaboration des

prévisions budgétaires PA et PMT de département (P).
Ce processus est composé de six objets qui représentent soit des processus métiers
eux même composés (Gestion Prévisions Production (P), Gestion Prévisions Maintenance
(M), Gestion Prévisions Approvisionnement (A), Gestion des Ressources (Bases de données))
soit des acteurs externes (Département Finance (F), DAG/MOG).
En se basant sur le plan de production, l’objet (P) invoque la base des articles pour
élaborer les prévisions PA et PMT des matières et fournitures liées à la production (articles
gérés en stock et ceux non gérés en stock), de fonctionnement (Matières et fournitures non
liées à la production, et missions) et de prestation de services et énergie (Prévisions
valorisées).
Dès que le processus d’élaborations des différentes prévisions est terminé, un
processus de validation des prévisions est exécuté afin de les corriger et les finaliser. L’objet
(A) communique ses besoins validés aux autres objets collaborateurs de la façon suivante :
Les prévisions de fonctionnement composées de prévisions de missions et de
prévisions de consommation des matières et fournitures non gérées en stock et non liée à la
production sont communiquées à l’objet (M) via le flux (P’’’1). Les prévisions valorisées
(prestation des services et énergies) sont transmises à l’objet (F) via le flux (P ’’). L’objet (P)
envoie à l’objet (A) les prévisions en matière d’articles gérés en stock via le flux (P1), et les
prévisions en matière d’articles non gérés en stock via le flux (P ’1).
Lui-même, l’objet (A) lance le processus d’élaboration des prévisions relatives à
son propre fonctionnement (Matières et fournitures non régies par une norme, Missions) et
des prévisions de dotation. Après réception des prévisions d’achat pour les articles gérés ou
non gérés en stock des différents centres de coût et en interrogeant les bases BSS/BRS et
BSD, l’objet (A) arrête les prévisions de consommations de ces articles et passe en suite à
l’exécution du processus de valorisation en utilisant la table des prix des produits. Un
processus de validation interne est bien sûr exécuté pour objectif de finaliser les prévisions.
L’objet (A) communique à l’objet (F) ses prévisions de dotation, de consommation des
articles gérés en stock et de ceux non gérés en stock via respectivement les trois flux (A ’), (P2)
et (P’2[A]). À l’objet (M) seront transmises les prévisions quantitatives de fonctionnement de
l’objet (A) via le flux (A1).
À son tour, l’objet (M) élabore ses différentes prévisions relatives aux achats et
consommations pour les articles gérés en stock, au fonctionnement (Matières et fournitures
non gérées en stock et de missions), aux achats pour articles non gérés en stock, aux
dotations, aux charges locatives et aux transports scolaire et universitaire en interrogeant
l’objet Base Personnel. Après avoir reçu les prévisions quantitatives des différents objets
collaborateurs, un processus de validation est exécuté. En se basant sur les réponses de
l’objet Table Produit/Prix, le processus de valorisation est exécuté pour les diverses
prévisions quantitatives. L’objet (M) transmet à l’objet (DAG/MOG) les prévisions de
transports scolaire et universitaire et celles des charges locatives, et à l’objet (F) les prévisions
de fonctionnement, les prévisions d’achat des articles non GS, les prévisions valorisées de
l’objet (A) et les prévisions valorisées de l’objet (P) respectivement via les flux (Mg1), (Mg2),
(Mg3), (A2[M]) et (P’’’2[M]).

2.2. Architecture du processus métier de département Approvisionnement (A)
- Description de l’architecture du processus (A):
Cette architecture représente le processus métier relatif à l’élaboration des

prévisions budgétaires PA et PMT de département (A).
l’objet (A) lance le processus d’élaboration des prévisions de fonctionnement
(Matières et fournitures non régies par une norme, Missions) et des prévisions de dotation.
Après avoir reçu les prévisions de consommations des objets collaborateurs P,G,T,I
et W , il arrête les prévisions de consommations de ces articles et passe en suite à l’exécution
du processus de valorisation en utilisant la table des prix des produits. Un processus de
validation interne est bien sûr exécuté pour objectif de finaliser les prévisions. L’objet (A)
communique à l’objet (M) ses prévisions quantitatives de fonctionnement via le flux (A 1) et

à l’objet (F) ses prévisions valorisées de dotation, de consommation des articles non gérés en
stock et de ceux gérés en stock via respectivement les trois flux (A ’), (CC2) et (CC’2).
Concernant l’objet (M), les mêmes processus que dans la section 2.1.
2.3. Architecture du processus métier de département Maintenance (G)
Description de l’architecture du processus (G): cette architecture est la même que

celle du processus (P) sauf que l’objet (G) n’a pas de prévisions d’énergie à élaborer et les
prévisions des matières et fournitures sont liées à la fonction maintenance..

2.4. Architecture du processus métier de département Sécurité Industrielle
Description de l’architecture du processus (I): Cette architecture est la même que celle du
processus (G).

2.5. Architecture du processus métier de département Moyens Généraux (M)
Description de l’architecture du processus (M): En consultant l’état du stock, l’objet

(M) élabore ses différentes prévisions relatives aux achats et consommations pour les articles
gérés en stock, au fonctionnement (Matières et fournitures non gérées en stock et de
missions), aux achats pour articles non gérés en stock, aux dotations, aux charges locatives et
aux transports scolaire et universitaire en interrogeant l’objet Base Personnel. Après avoir
reçu les prévisions quantitatives des différents objets collaborateurs, un processus de
validation est exécuté. En se basant sur les réponses de l’objet Table Produit/Prix, le
processus de valorisation est exécuté pour les diverses prévisions quantitatives. L’objet (M)
transmet à l’objet (DAG/MOG) les prévisions de transports scolaire et universitaire et de
charges locatives, et à l’objet (F) les prévisions de fonctionnement, les prévisions d’achat des
articles non GS, les prévisions valorisées de tout les objets collaborateurs.

2.6. Architecture du processus métier de département Technique (T)
Description de l’architecture du processus (T): cette architecture est la même que

celle du processus (G).

2.7. Architecture du processus métier de département Travaux Neufs (W)
Description de l’architecture du processus (W): Cette architecture est la même que

celle du processus (G) sauf que l’objet (w) n’a de prévisions des matières et fournitures que
pour le fonctionnement.

3. Représentation relationnelle du modèle statique
Le passage vers le modèle relationnel est soumis à un ensemble de règles. Ce

passage donne lieu au modèle logique de données (MLD) que nous allons décrire sous la
forme relationnelle par le schéma relationnel de la base de données.
3.1. Règle de passage du modèle conceptuel au modèle relationnel
 Toute classe mère du diagramme de classes devient une table de la base de données
avec comme clé primaire l’identifiant de la classe.
 Toute classe fille du diagramme de classes devient une table avec comme clé
primaire composée de la concaténation de son identifiant et ce lui de la classe mère
correspondante.
 Toute classe associative devient une table avec comme clé primaire composée de la
concaténation de son identifiant et ceux des classes participant à l’association.
3.2. Schéma du modèle relationnel relatif au modèle statique conçu
1) Département(Code département, désignation département)

2) Article(Code article, désignation article, unité mesure, n°compte comptable)
3) Matières_Fournitures(Code article, désignation article, unité mesure, n°compte
comptable, type mat_four, nature mat_four)
4) Paramètre(Code article ,Numéro paramètre, valeur paramètre)
5) Destination(Code destination, désignation destination, type destination)
6) Manifestation(Code manifestation, Code destination, désignation, n°compte
comptable)
7) Prestation de services(Code prestation, désignation prestation, type prestation,
n°compte comptable)
8) Recettes(Code recette, désignation recette, nature recette, n°compte comptable)
9) Missions(Code manifestation, Code destination, désignation, n°compte comptable,
motif mission)
10) Formations(Code manifestation, Code destination, désignation, n°compte
comptable, type formation)
11) Charges diverses(Code charges diverses, désignation charges diverses, n°compte
comptable)
12) Energie(Code article, désignation article, unité mesure, n°compte comptable)
13) Rubrique(Code rubrique, libellé rubrique, n°compte comptable)
14) Fonction personnel(Code fonction, libellé fonction, n°compte comptable)
15) Employés(Matricule, code fonction)
16) Prévisions article(Code département, Code article, Numéro prévision, exercice,
mois, quantité, montant prévision DA, montant prévision devises)
17) Prévisions prestations(Code département, Code prestation, Numéro prévision,
exercice, mois, montant prestation DA, montant prestation devises)

18) Prévisions recettes(Code département, Code recette, Numéro prévision, exercice,

mois, montant recettes DA, montant recettes devises)
19) Prévisions manifestation(Code département, Code manifestation, Numéro
prévision, exercice, mois, nombre de personnes, date début, date fin, coût
manifestation)
20) Prévisions charges diverses(Code département, Code charges diverses, Numéro
prévision, exercice, mois, nombre de personnes, montant prévision)
21) Prévisions salaire(Code département, Code fonction, Numéro prévision, exercice,
mois, effectif, type effectif, montant)
22) Prévisions rubrique(Code département, Code fonction, Code rubrique, Numéro
prévision, exercice, mois, nombre effectif, type effectif, montant).
 La clé est indiquée par l’attribut(s) souligné(s).

Conclusion générale
Conclusion Générale 98
Conclusion générale
Ce travail nous a permis en premier lieu de se familiariser avec l'environnement

UML et workflow.
Nous avons parlé dans le premier chapitre du langage UML en présentant ses
principaux diagrammes utilisés dans la modélisation des systèmes. Dans le deuxième
chapitre, nous avons abordé la technologie des workflows qui a pris une position importante
dans la gestion des processus des organisations.
Le troisième chapitre est consacré pour la présentation du langage d’exécution des
processus métiers (Business Process Execution Language). Ce langage ‘BPEL’ va être utilisé
dans la validation de notre modélisation workflow dans le chapitre cinq.
Après avoir étudié le cahier charge présenté par l’équipe de l’organisme d’accueil
AVAL/SONATRACH, et suite aux explications et éclaircissements retenues lors des
différentes séances de travail tenues avec l’équipe AVAL/SONATRACH et notamment les
responsables de département informatique et ceux des finances, nous avons pu concevoir le
système d’information relatif au processus activité budgétaire réalisé aux niveaux des
différentes structures de l’activité AVAL/SONATRACH.
Dans notre démarche de conception, nous avons présenté une modélisation
statique décrite par le diagramme des classes vu dans la section 4.1 du chapitre IV, puis nous
avons entamé une modélisation dynamique en élaborant vingt (20) diagrammes d’activités,
dont certains sont cités dans la section 4.2 du chapitre IV, et d’autres dans l’annexe 1. Par la
suite et dans la section 5.2, nous avons appliqué le workflow à ces derniers diagrammes
pour réaliser notre modélisation workflow des différents processus métiers composant le
système de l’activité budgétaire. Cette modélisation est enrichie d’une description textuelle
de chaque processus.
Dans le cinquième chapitre nous avons réalisé la validation des diagrammes
workflows conçus, pour cela, nous avons choisi le langage BPEL présenté dans le chapitre
III. Afin de réaliser cette validation nous avons implémenté quelques diagrammes en

Conclusion Générale 99
utilisant l’éditeur du logiciel MagicDraw . En exécutant la fonction ‘Exporter vers BPEL’, et

dans le cas d’absence d’erreur, un fichier BPEL sous format XML est généré.
Dans le chapitre VI, nous avons aussi conçu sept (7) architectures métiers pour
préparer l’étape de l’implémentation du système de l’activité budgétaire AVAL et qui n’est
pas notre objectif dans ce travail.
En fin, nous avons représenté la structure relationnelle de la modélisation statique
UML vue dans la section 4.1 du chapitre IV. Cette représentation permettra dans le futur de
concevoir la base de données relative au processus activité budgétaire AVAL.
La continuité de ce travail est de réaliser un logiciel intégrant cette modélisation
traitant les prévisions budgétaires au sein de toutes les structures de Aval/Sonatrach.

Annexe 01
La suite de la contribution :
Modélisation des diagrammes
d’activités UML
Annexe 01 – Compléments des diagrammes d’activités modélisés 100
A01.1. Diagramme d'activités du Budget PA et PMT élaboré par le

département Maintenance (G)


département Technique (T)


département Sécurité Industrielle (I)


département Travaux Neufs (W)

A01.5. Diagramme d'activités du Budget PA et PMT élaboré par la

Direction de l’unité, D*E et D*S

A01.6. Diagramme d'activités du Budget PA et PMT élaboré par le Service

Relations du Travail (RT)

A01.7. Diagramme d'activités du Budget PA et PMT élaboré par le Conseil

Syndical

A01.8. Diagramme d'activité du processus de validation des prévisions des

stocks, d’achats et consommations des articles gérés en stock (A) du
plan annuel et PMT

A01.9. Diagramme d'activité du processus de validation des prévisions

d’achats et consommations pour les articles non gérés en stock (A)
du plan annuel et PMT

A01.10. Diagramme d'activité du processus de validation des prévisions

consolidées d’achats et consommations pour les articles non gérés en
stock (M) du plan annuel et PMT


département Passation des Marchés (PM)

département Approvisionnement (A)

département Moyens Généraux (M)

département Ressources Humaines (R)

département Administration et Social (S)

département Système d’information et de Gestion (SIG)
A01.17. Diagramme d'activités du Budget PA et PMT élaboré par

l’Assistant Sûreté Interne (ASI)
Annexe 02
La suite de cahier de charges

Annexe 02 – Cahier de charges du projet d'informatisation du processus budgétaire au sein de l'Activité Aval - Oran 117
Sonatrach/Activité Aval
Direction Finances
Département Budget et Contrôle de Gestion
Projet de formalisation et
d’informatisation des processus
de gestion budgétaire et
reporting au sein de l’Activité
Aval/Sonatrach
Volets Exploitation et
Financement
Version 1.0

Sommaire
Eléments de cadrage du projet

I) Etat des lieux par processus
1) Description du déroulement de la campagne budgétaire
1- Le lancement de la campagne budgétaire
2- L’élaboration des prévisions budgétaires :
3- Le Pré-arbitrage du projet de PA et PMT Unité
4- Le Pré-arbitrage du projet de PA et PMT Division
5- Arbitrage du projet de PA et PMT Activité Aval
6- Contrôle et consolidation du projet de PA et PMT et transmission à la DCGF/SH
7- Notification du Plan Annuel N+1
2) Supports de collecte de l’information concernant le plan annuel et PMT
2.1 Support interne à l’Unité
2.2 Canevas du Plan Annuel et PMT SONATRACH
II) Objectifs généraux du projet par processus
1) Elaboration du budget et PMT afférents aux volets exploitation et financement
2) Elaboration des documents de Reporting afférents aux volets exploitation et
financement
3) Contrôle budgétaire
III) Procédure d’élaboration du plan annuel et PMT volet exploitation et financement
1- Processus d’élaboration du budget et PMT afférents aux volets exploitation:
1.1- Différents plans (plan annuel et PMT):
1.2- Types de budgets et PMT par structure et par fonction
1.3- Hiérarchisation des budgets et PMT
Eléments de cadrage du projet
1. Le projet concerne les volets Exploitation et financement, conformément aux missions
dévolues à la Direction Finances en tant que structure consolidante de ces volets dans le cadre
de l’élaboration du Plan Annuel et PMT, en respect de l’organisation en place,
2. Le projet devra tenir compte des interfaces à établir avec les autres volets à considérer dans
d’élaboration du Plan Annuel et PMT afférents aux volets Flux et Investissements, relevant
d’autres Structures de l’Activité Aval (EXP, MNT, TEC, PLS, RHU) pour des impératifs de
cohérences,
3. Le projet touchera les processus suivants :
 Elaboration du budget annuel pour les périodes clôture N, N+1 et les périodes du
PMT (N+2, N+3, N+4 et N+5), conformément aux procédures en vigueur de
Sonatrach,
 Elaboration du reporting périodique sur le suivi d’exécution des budgets notifiés,
 Contrôle budgétaire à priori.
4. Le périmètre d’intervention du projet concerne les unités opérationnelles et les structures
fonctionnelles de l’Activité Aval.

I) Etat des lieux par processus
1) Description du déroulement de la campagne budgétaire

Le processus d'élaboration du Plan Annuel et PMT, s’étend d’avril de l’année N à janvier de
l’année N+1. Ce processus est constitué de sept grandes étapes (cf. schéma n°1) :
1. Le lancement de la campagne budgétaire
2. L’élaboration des prévisions budgétaires
Le Pré-arbitrage du projet de PA et PMT Unité
3. Le Pré-Arbitrage du projet de PA et PMT Division
4. L’arbitrage du projet de PA et PMT Activité Aval
5. Contrôle et consolidation du projet de PA et PMT et transmission à la DCGF/SH
6. Notification du budget N+1
1-Le lancement de la campagne budgétaire

Le lancement officiel de la campagne budgétaire s’effectue généralement le mois d’Avril de
l’année N, après l’achèvement des travaux de bilan N-1.
A l’initiative du Département finances, une note signée par le Directeur est envoyée aux différentes
structures de l’Unité pour leur signifier le début des travaux ainsi que l’échéance retenue pour la
transmission des supports de collectes dûment renseignés par leurs soins.
Cette note est accompagnée d’une synthèse de la directive cadre du précèdent plan annuel et du
planning des réunions de préparation et validation internes à l’Unité, en attendant la diffusion par
l’Activité Aval de la Directive cadre du nouveau Plan Annuel et PMT.
La note définit les différents axes et orientations pour l’élaboration des prévisions dans le respect des
directives et politiques en vigueur au sein de l’Activité dans les différents domaines.
La note transmise aux différentes structures est également accompagnée de supports de collecte de
prévisions confectionnés par les services de l’Unité.
Il est à signaler que la Directive cadre diffusée par l’Activité Aval, en attendant la note d’orientation
générale vulgarisée par la Direction Générale de Sonatrach est accompagnée des hypothèses d’entrée et
normes afférentes, principalement à :
 La parité des principales Devises par rapport au Dinar à considérer pour les opérations
libellées en Devises,
 Le taux d’inflation,
2- L’élaboration des prévisions budgétaires :

Chaque structure élabore et transmets ses prévisions, en tenant compte des principes
suivants :
 Adéquation entre les prévisions et les objectifs ciblés,
 Analyse quantitative et qualitative des prévisions,
 Justification de l’opportunité de chaque opération,
 Maturation de chaque opération, par rapport au processus de passation de marchés (existence
de cahier des charges),
Chaque poste budgétaire inscrit sur le support des charges de la structure est expliqué avec
le maximum de détails, pour permettre aux services financiers de l’Unité de fournir les explications
nécessaires lors des présentations des projets de PA et PMT pour pré-arbitrage.
Une fois toutes les prévisions de toutes les structures transmises au département finances et avant
l’entame de l’opération de consolidation par ce dernier,des réunions sont tenues avec les structures
concernées,afin de corriger les éventuelles erreurs ou incohérences.

3- Le Pré-arbitrage du projet de PA et PMT Unité

Après les réunions avec les différentes structures, le pré-arbitrage en interne à l’Unité est
présidé par le Directeur, en présence de tous les responsables des départements, y compris le chef
département Finances, secondé par le service informations de gestion qui aura à charge de noter
toutes les orientations du Directeur et veiller à ce qu’elles soient portées sur le PV de réunion.
Lors de cette séance de pré arbitrage, les prévisions budgétaires consolidées de l’Unité concernant le
volet exploitation sont soumises à l’examen et la validation de la Direction, compte tenu des différents
plans d’actions, parmi lesquels :
 Plan de production,
 Plan de maintenance,
 Plan d’investissement,
 Plan formation, effectifs, salaires,
 Prévision des charges,
A l’issu de ce pré-arbitrage, des corrections et actualisations sont portées sur le projet du plan annuel et
PMT exploitation de l’Unité.
Sur la base du plan annuel et PMT exploitation, ainsi validé par le Directeur de l’Unité, une synthèse
est élaborée pour les besoins de l’opération de pré-arbitrage par le niveau hiérarchique supérieur.
4- Le Pré-arbitrage du projet de PA et PMT Division

Le plan annuel et PMT validé par le Directeur de l’Unité est présenté par ce dernier au
Directeur de la Division, en présence des directeurs centraux TEC, MNT, EXP, PLS, FIN, RHU, ISI.
Ce pré-arbitrage concerne toutes les unités relevant de la Division et se fait suivant un planning arrêté.
Les volets examinés lors de ces séances de pré -arbitrage sont synthétisés comme suit :
 Plan de maintenance,
 Plan d’investissement,
 Prévisions des charges d’exploitation,
 Prévisions de coût de process, de coût de maintenance, de coût de sécurité,
 Evolution prévisionnelle des stocks de matières et fournitures.
Les décisions prises et orientations données lors de ces réunions sont consignées sur un Procès Verbal
et donneront lieu à des corrections et actualisations que l’Unité portera sur son plan annuel et PMT,
avant de le remettre aux directions centrales concernées qui procèderont aux consolidations requises
par volets, aux fins de présentation à l’arbitrage par Monsieur le Vice-Président en CCA (Comité de
Coordination de l’Activité).
5-Arbitrage du projet de PA et PMT Activité Aval

L’arbitrage du Plan Annuel et PMT de l’Activité Aval se fait en CCA par Monsieur le Vice-
président, en présence de tous les responsables de Structures qui présentent les grands objectifs
retenus, aussi bien en matière d’exploitation que d’investissement pour l’exercice budgétaire suivant et
sur le Plan à Moyen Terme.
Lors de cet arbitrage, d’ultimes orientations et directives sont données par Monsieur le Vice-président,
notamment pour les opérations dont l’importance requiert sa décision.
Lesdites orientations et directives sont consignées dans un Procès Verbal et donneront lieu aux
derniers ajustements et actualisations par les unités, avant que les Structures Centrales ne procèdent à
la consolidation finale du Plan Annuel et PMT, chacune pour le volet dont elle est chargée.
A cette étape, la Direction Finances/Aval se charge de la consolidation du volet Exploitation et
financement.

6-Contrôle et consolidation du projet de PA et PMT et transmission à la DCGF/SH

Après l’arbitrage et l’adoption du Plan Annuel et PMT de l’Activité en CCA, toutes les Unités
procèdent à la saisie des dernières corrections et actualisations sur les canevas du volet Exploitation et
financement, avant de les transmettre aux services concernés de la Direction Finances/Aval.
Ces derniers, après vérification de cohérences et contrôle de l’état de saisie des informations sur les
canevas appropriés, procèdent à la consolidation et la transmission des documents des Unités, par
courrier électronique, aux services concernés de la Direction Générale Sonatrach (DCGF/SH).
Les travaux de consolidation portent, entre autres, sur:
 Vérification des saisies,
 Vérification de l’application des décisions prises lors du pré-arbitrage Division et arbitrage
CCA,
 Contrôle de cohérences avec les autres volets,
 Rapprochement des opérations inter unités,
 Rapprochement des paiements pour compte dans le budget de financement d’exploitation.
7-Notification du Plan Annuel N+1

En début janvier de l'année N+1, la DCG FIN procède à l’élaboration des décisions
d’exécution du Plan Annuel de l’année N+1 pour les volets Budget d’Exploitation et Plan de
Financement dans le respect du Plan consolidé approuvé par les Organes Sociaux de Sonatrach SPA et
les soumettent à la signature du président Directeur Général.
La notification est transmise, généralement, en janvier de l’année n+1. Elle a valeur d’autorisation
budgétaire et marque le début d'exécution du Plan Annuel au sein des unités opérationnelles.
Les sept étapes sont synthétisées dans le schéma ci-dessous :
Principales étapes
Directive cadre d’élaboration du PA et PMT et Avril N

Lancement de la campagne budgétaire
Elaboration du PA et PMT
Validation au niveau Unité

Juin à Juillet
Pré arbitrage du PA et PMT au niveau des Divisions N
Septembre N
Arbitrage du PA et PMT au niveau du CCA
Octobre N
Transmission du PA et PMT consolidé AVAL à la DCGF/SH
Janvier N+1
Notification du Plan Annuel N+1
Schéma 1 : Les grandes étapes du processus d’élaboration du PA et PMT.

2) Supports de collecte de l’information concernant le plan annuel et PMT

Ces supports sont à classer en deux (02) grandes catégories :
 Supports de collecte des prévisions internes à l’Unité,
 Canevas du Plan Annuel et PMT Sonatrach.
2.1 Support interne à l’Unité
Il s’agit de tableaux Excel transmis par messagerie par le Département Finances à toutes les autres
Structures de l’Unité, afin d’y renseigner leurs besoins prévisionnels en matière de budget de
fonctionnement pour les exercices à venir en fonction des objectifs opérationnels inscrits sur le PMT.
A titre d’exemple, le canevas utilisé au niveau du complexe GL2Z est donné en annexe n°1.
2.2 Canevas du Plan Annuel et PMT SONATRACH
Le canevas du Plan Annuel et PMT, se présentant sous forme de tableaux Excel, est celui arrêté par les
services de la Direction Générale Sonatrach (DCGF) et que chaque Unité se doit de respecter pour
communiquer ses prévisions budgétaires dans le but de les consolider et de les notifier.
Il existe deux types de canevas de saisie destinés aux services de la DCGF/Sonatrach, selon le volet
concerné : canevas du volet Exploitation et canevas du volet Financement des Investissements.
2.2.1 Canevas du volet Exploitation
Le canevas se présente sous forme de tableaux Excel, indiquant pour la plus part :
1. Les montants réalisés de l’exercice N-1,
2. Les prévisions de clôture N,
3. Les prévisions de l’exercice budgétaire N+1 (à notifier),
4. Les prévisions sur le PMT.
Selon leur contenu, ces tableaux sont classés comme suit :
1. Tableaux des Comptes de Résultats prévisionnels,
2. Tableaux des prévisions de charges d’exploitation,
3. Tableaux des prévisions de produits d’exploitation,
4. Tableaux des prévisions de coûts de maintenance,
5. Tableaux des prévisions de coûts de sécurité industrielle,
6. Tableaux des prévisions de coûts de sûreté interne,
7. Tableaux des prévisions de charges investies,
8. Tableaux des prévisions de coûts de processing ou de production,
9. Tableaux des prévisions de stocks de matières et fournitures,
10. Tableaux des prévisions de financement d’exploitation
2.2.2 Canevas du volet Financement des Investissements
Sous forme d’une macro Excel, ce fichier permet la saisie, pour chaque opération d’investissement :
a) Les prévisions physiques valorisées, étalées sur les périodes du Plan Annuel et PMT, mettant
en exergue :
 La source de financement (interne et/ou externe),
 La partie en biens et la partie en services de la prévision
 Les parties en Dinars et en Devises de la prévision,
b) La prévision d’autofinancement pour l’exercice N+1 à notifier et mettant en exergue :
 La partie en biens et la partie en services de la prévision
 La partie en Dinars et en Devises de la prévision,
La somme de toutes les prévisions d’autofinancement de l’exercice N+1 constitue le budget de
décaissement des Investissements de l’Unité, à notifier, pour cet exercice.
II)Objectifs généraux du projet par processus

1) Elaboration du budget et PMT afférents aux volets exploitation et financement
1. Formalisation et uniformisation d’une procédure.
2. Automatisation de la collecte des prévisions, des mises à jour et consolidation au niveau Unité.
3. Automatisation des mises à jour et consolidation au niveau central.

4. Etablissement des prévisions par centre de coût et/ou par centre de responsabilité
budgétaire, par nature et par mois pour les périodes N et N+1.
5. Amélioration de la fiabilité des prévisions budgétaires par la mise en place de
paramétrages entre objectifs opérationnels et prévisions de consommation de biens et de
services.
6. Instauration d’un système de validation des prévisions budgétaires (CC, CRB, Unité,
Division, Activité).
7. Etablissement des coûts d’exploitation prévisionnels par fonction (voir résultats projet
CAE pour intégration).
8. Etablissement d’une hiérarchisation et interdépendance des budgets (production,
investissement, charges par fonction, achats…).
9. Traitement et rapprochements automatisés des opérations inter-unités (prestations, PPC).
10. Modèle de présentation uniforme pour arbitrages.
2) Elaboration des documents de Reporting afférents aux volets exploitation et financement
1. Formalisation et uniformisation d’une procédure.
2. Automatisation du report des réalisations périodiques sur les canevas à partir des bases de
données existantes (CAE, CPT Gle, trésorerie).
3. Identification et explication des écarts par centre de coût.
4. Automatisation de la consolidation au niveau central (Direction Finances).
5. Mise en place de tableaux de bord pour suivi d’indicateurs clés de performance à identifier
3) Contrôle budgétaire
- Formalisation et uniformisation d’une procédure de contrôle et de suivi d’exécution des
budgets, par CC et/ou CRB. Ce contrôle à priori concerne, notamment :
 Le budget d’approvisionnements, c’est-à-dire les sommes prévues d’être payées aux

fournisseurs de biens,
 Le budget des services, c’est-à-dire les sommes prévues d’être payées aux
fournisseurs de services,
 Le budget des investissements, c’est-à-dire les sommes prévues d’être payées aux
fournisseurs d’investissements,
- Formalisation et uniformisation d’une procédure.
III) Procédure d’élaboration du plan annuel et PMT volet exploitation et financement

La procédure est basée sur la notion du « qui fait quoi », compte tenu :
 Des différents Plans existant et qui sont déterminants dans le processus d’élaboration des
prévisions budgétaires et PMT,
 De l’Organisation en place, aussi bien au niveau opérationnel que fonctionnel.
1-Processus d’élaboration du budget et PMT afférents aux volets exploitation:

1.1- Différents plans (plan annuel et PMT):
Il s’agit des plans préalablement élaborés reflétant les différents objectifs opérationnels inscrits sur les
PMT(s). Parmi ces plans, il est cité :
 Plan de maintenance
 Plan de formation
 Plan de recrutement
 Plan HSE
 Plan d’investissements
 Plan d’approvisionnements
 Plan de passation de marchés

 Plan de ventes des biens et services

 Plan de mission
1.2- Types de budgets et PMT par structure et par fonction
Les types de budgets sont calqués sur l’organisation en place au niveau opérationnel et fonctionnel, en
respect des missions dévolues aux différents acteurs intervenants dans le processus d’élaboration des
prévisions dans le cadre de la campagne budgétaire.
A titre d’exemple, l’organisation commune en place au sein d’une Unité opérationnelle de la Division
LQS se décline comme suit :
 Département production
 Département maintenance
 Département approvisionnements
 Département Administration et sociale
 Département DRH
 Département moyens généraux
 Département technique
 Département travaux neufs
 Département sécurité industrielle
 Département finances
 sûreté interne (assistant)
 Département système d’information et de gestion
 relations du travail (service)
 Département passation des marchés
 sous direction exploitation D*E
 sous direction personnel D*S
 conseil syndical
Il est à relever que les Structures fonctionnelles de l’Activité Aval élaborent également leurs
prévisions budgétaires qui sont consolidées au niveau de la Direction Administration Générale/Aval
en tant qu’Unité comptable et budgétaire du Siège/Aval.
Ces Structures fonctionnelles sont également impliquées dans le processus d’élaboration du Plan
Annuel et PMT des Unités opérationnelles dans son volet Exploitation en tant que Structures
consolidantes, chacune dans son domaine.

1.3- Hiérarchisation des budgets et PMT

Les différents budgets élaborés par les structures de l’Unité, conformément à l’organisation en place, se
déclinent ci-dessous avec identification du « qui fait quoi » en fonction des missions dévolues à
chacune d’elles.
1) Budget élaboré par le Département Production (P)

Objectif : budget exprimant les consommations en matières premières nécessaires à l’atteinte des
objectifs de production arrêtés et les moyens de fonctionnement internes à la structure.
a) Budget et PMT de la fonction production:
- Acteurs impliqués : Direction Exploitation LQS, D*E, P, G et A unité.
 Plans : plan de production
 produits chimiques (tamis moléculaires, inhibiteur de corrosion…)
 énergies (électricité, utilités, eau, gaz naturel autoconsommé, gaz
industriels)
 lubrifiants
 carburants
- Prévisions de prestations de services : redevances d’occupations terre plein et plan
d’eau « STH »
c) Budget et PMT de fonctionnements de la structure P :
- Fournitures consommées (non régies par une norme) : Produits sociaux, outillages,
consommation de fournitures diverses et produits de fonctionnement, fournitures de
bureaux spécifiques, consommables informatiques…
Acteur /
Intervenant
EXP et Plan de production
Projet de Plan de production
dép. P (annexe)
Elaboration et transmission des prévisions PA (par mois

pour N et N+1) et PMT (de N+2 à N+5) de consommation
de :
 Matières et fournitures gérées en stock liées à la Dép. A Pour prise en compte
production (quantitatifs selon paramétrages) dans le budget achat A
 Matières et fournitures pour fonctionnements non (annexe)
régies par une norme, non gérées en stock et liées à Dép. A Pour compléter
la production (prévisions quantitatives) budget achat A
 Matières et fournitures pour fonctionnements non (annexe)
régies par une norme, non gérées en stock et non Pour compléter
Dép. P
liées à la production (prévisions quantitatives) Dép. M budget achat M
 Energies (prévisions valorisées) (annexe)
Elaboration et transmission des prévisions quantitatives de Dép. F Pour intégration dans

missions pour PA (par mois pour N et N+1) et PMT (de le budget trésorerie
N+2 à N+5) Dép. M Annexe
Etat des missions
Elaboration et transmission des prévisions valorisées de détaillé (annexe)
prestation de services pour PA (par mois pour N et N+1) - Pour intégration
et PMT (de N+2 à N+5) Dép. F dans le budget
trésorerie

2) Budget élaboré par le Département de la Maintenance (G)

Objectif : budget exprimant les consommations en matières et fournitures (PDR et consommables) et
services nécessaires à la réalisation du plan de maintenance de l’Unité et les moyens de
fonctionnement internes à la structure.
a) Budget et PMT de la fonction maintenance :
- Acteurs impliqués : MNT et EXP/LQS, D*E, G, P, A, M et T unité.
 Plans : plan de maintenance (planning des arrêts), plan d’investissement IMFS
- PDR pour matériels, fournitures électriques, petit outillage, matériaux de
construction…
- produits chimiques
- gaz industriels
- lubrifiants
- Prévisions de prestations de services : contrats de prestations (diverses prestations de
maintenance, réparations…)
- Description des opérations par contrat, convention et par nature (peinture des
installations et bâtiments, re-bobinages, location de matériels et engins, …)
b) Budget de fonctionnements de la structure G :
- Fournitures consommées (non régies par une norme) : Produits sociaux, outillages,
consommation de fournitures diverses et produits de fonctionnement, fournitures de
bureaux, consommables informatiques…
Acteur /
Action / Description Destinataire Observation / support
Intervenant
Dép. G, Dép. P
Plan de maintenance
Dép. T, Dép. A, Projet de Plan de maintenance
(annexe)
MNT et EXP
quantitatives de consommation de
fournitures PA (par mois pour N et N+1) et
PMT (de N+2 à N+5)
 PDR et Matières et fournitures Pour prise en compte
gérées en stock liées à la Dép. A dans le budget achat A.
maintenance préventive
(quantitatifs selon paramétrages)
 PDR et Matières et fournitures non Dép. A Pour compléter budget
gérées en stock liées à la achat A (annexe)
maintenance préventive
 Matières et fournitures pour Pour compléter budget
Dép. G
fonctionnement non régies par Dép. M achat M (annexe)
une norme non gérées en stock et
non liées à la production
Etat des missions
Elaboration et transmission des prévisions Dép. M détaillé (annexe)
quantitatives de missions pour PA (par mois
pour N et N+1) et PMT (de N+2 à N+5)
-Prestations
Elaboration et transmission des prévisions Dép. F contractuelles (annexe)
valorisées de prestation de services PA (par -Pour prise en compte
mois pour N et N+1) et PMT (de N+2 à N+5) dans le budget
liées a la maintenance trésorerie

3) Budget élaboré par le Département des Approvisionnements (A)

Objectif : Le budget des approvisionnements a pour objectif d’arrêter pour les structures, de
l’Unité les niveaux des matières et fournitures à acquérir, compte tenu de leurs
consommations prévisionnelles, du stock existant et du niveau du stock de sécurité, par
article.
Le Département A prévoit également ses besoins dans le cadre de son fonctionnement.
a) Budget et PMT de la fonction approvisionnements :
- Acteurs impliqués : P, G, T, I et W
 Prévisions de consommations des structures P, G, T, I et W en matières et fournitures
gérées en stock en quantités.
 Politique de réapprovisionnement (stocks de sécurité en quantités).
 Stocks existants en quantités.
 Table des prix : coûts unitaires d’achat (décomposés en prix d’achat et frais
d’approche) et les coûts unitaires moyens pondérés (CUMP)
- Prévisions de dotations aux provisions pour dépréciation des stocks
b) Budget de fonctionnements de la structure A :
- Fournitures consommées (non régies par une norme) : Produits sociaux, articles
consommables (PDR matériels roulants et de levages, fournitures électriques,
outillages,….), fournitures de bureaux, …
Acteur /
Intervenant
Dép. P Dép. G Annexe pour Dép. P
Plan des prévisions des consommations des Dép. A
Dép. T Dép. I et Dép. G Dép. T
articles gérés et non gérés en stock en quantités.
Dép. W Dép. I Dép. W
Elaboration et transmission des prévisions PA
(par mois pour N et N+1) et PMT (de N+2 à
N+5) :
 Prévisions consolidées d’achats Pour prise en compte
(entrées stock) en Dinars et Devises et dans la consolidation
consommations (sorties stock) pour les Dép. F des charges et dans le
articles gérés en stock (A) (prévisions budget trésorerie
valorisées) (Annexe).
 Prévisions consolidées (Unité) des
achats en Dinars et Devises pour les Pour prise en compte
articles non gérés en stock (A) : Dép. F dans la consolidation
consommations directes (prévisions des charges et dans le
Dép. A
valorisées) budget trésorerie .
 Matières et fournitures pour Pour compléter
fonctionnement A non régies par une Dép. M budget achat M
norme (prévisions quantitatives) (annexe).
 Dotations aux provisions pour Pour prise en compte
dépréciation des stocks gérés par A Dép. F dans la consolidation
(prévisions valorisées) des charges.
Elaboration et transmission des prévisions Etat des missions

quantitatives de prestation de services Dép. M détaillé (annexe) .
(missions) pour PA (par mois pour N et N+1) et
PMT (de N+2 à N+5)

4) Budget élaboré par le Département des moyens généraux (M)

Objectif : le budget des moyens généraux a pour objectif de mettre à la disposition de l’unité et de
ses structures les matières, fournitures et services nécessaires à leur fonctionnement.
a) Budget et PMT de la fonction moyens généraux :
- Acteurs impliqués : toutes les structures
 Les normes de consommations en quantités, par structure, concernant les matières et
fournitures gérées en stock.
 Les normes afférentes aux prestations de services (liées au paramètre effectif ou
autres normes).
 Manuel EIP.
 Politique de gestion des stocks.
 Table des prix : coûts unitaires d’achat et les coûts unitaires moyens pondérés
(CUMP)
 Liste du nombre prévisionnel d’enfants des bases de SONATRACH concernés par le
transport scolaire et universitaire.
 Liste du nombre prévisionnel d’agents concernés par les loyers et charges locatives.
- Informations (output)
 Budget des consommations consolidés Unité et des achats valorisés pour les matières
et fournitures.
 Budget des prestations de services valorisé consolidé Unité (transport du personnel,
restauration, hygiène, désherbage, entretien espaces verts, maintenance des
véhicules, maintenances des appareils, contrôle technique, …)
transport scolaire et universitaire à transmettre à DAG/MOG.
 Liste du nombre prévisionnel d’agents concernés par les loyers et charges locatives
à transmettre à DAG/HR.
- Prévisions de dotations aux provisions pour dépréciation des stocks
- Prévisions taxes liées au parc roulant (vignettes et divers timbres)
b) Budget de fonctionnements de la structure M :
- Fournitures consommées (non régies par une norme) : Produits sociaux, articles
consommables, fournitures électriques, outillages,….
Acteur /
Action / Description Destinataire Observation / projection / support
Intervenant
Plan de prévisions quantitatives des consommations
Toutes les des articles non gérés en stock et non régie par une
Dép. M
structures norme (par mois pour N et N+1) et PMT (de N+2 à
N+5) pour valorisation par M
-Elaboration et transmission des prévisions valorisées
et consolidées PA (par mois pour N et N+1) et PMT
(de N+2 à N+5) :
 Prévisions consolidées d’achats (entrées Pour prise en compte dans la
stock) et consommations (sorties stock) Dép. F consolidation des charges et dans le
pour les articles régies par une norme et budget trésorerie
gérées en stock (M)
 Prévisions consolidées (Unité) d’achats des
Dép. M
matières et fournitures non régies par une Pour prise en compte dans la
norme et non gérées en stock (prévisions Dép. F consolidation des charges et dans le
valorisées) budget trésorerie
 Prévisions consolidées (Unité) de missions
des structures de l’Unité et les missions de Dép. F Etat des missions et de formations
formations détaillé par structure (annexe)
 Prestations de services
 Taxes parc automobile Dép. F Pour prise en compte dans la

 Dotations aux provisions pour Dép. F consolidation des charges

dépréciation des stocks gérés par M Prestations contractuelles (annexe)
(prévisions valorisées) Dép. F Annexe
-Transmission de la liste du nombre prévisionnel
d’enfants des bases de SONATRACH concernés par le Pour valorisation et transmission a
transport scolaire et universitaire DAG/MOG DAG/FJ qui transmettra aux F Unités
- Transmission de la liste du nombre prévisionnel Pour valorisation et transmission a
d’agents concernés par les loyers et charges locatives. DAG/MOG DAG/FJ qui transmettra aux F Unités
5) Budget du département ressources humaines (R)

Objectif: le budget du département ressources humaines a pour objectif de valoriser les prévisions
de formation et les taxes y afférentes (formation et apprentissage), retenues dans le plan
emploi, salaires et formation de l’Unité. Par ailleurs, le département R élabore le plan des
effectifs (départ/recrutement) de l’Unité par corps de métiers.
a) Budget et PMT de la fonction R
- Acteurs impliqués : R, RHU/Aval
 Plan de formation
 Prix unitaires des formations et séminaires
 Besoins organigramme de l’Unité
 Plan des départs en retraite.
 Budget et PMT de prestations de formation externe et inter/unité SH valorisé.
 Budget des taxes de formation.
 Plan des effectifs (départs/recrutements).
- Fournitures consommées en quantités liées à la formation sur site (non régies par une
norme) : Produits sociaux, articles consommables, fournitures de bureaux.
- Prestations de services : Nombre des missions pour formations par destinations
consolidé.
b) Budget de fonctionnements de la structure R :
Acteur /
Intervenant
RHU/Aval
Plan de Formation arbitré
et Dép. R
mois pour N et N+1) et PMT (de N+2 à N+5) :
 Budget et PMT de prestations de Pour prise en compte dans le
formation externe et inter/unité SH Dép. F budget trésorerie et /ou charges
valorisé. inter/unité
 Budget des taxes de formation valorisé
Dép. R  Fournitures consommées en quantités Dép. F Pour prise en compte dans le
liées à la formation sur site (non régie par budget trésorerie
une norme) Dép. M Pour compléter budget achat M
 Nombre des missions pour formations (annexe x)
par destinations consolidées Dép. M Etat des missions de formations
 Nombre des missions de R par détaillé (annexe x)
destinations Dép. M Etat des missions détaillé (annexe)
6) Budget du département administration et social (S)

Objectif: le budget du département administration et social a pour objectif d’élaborer les prévisions
de la masse salariale sur le plan annuel et PMT de l’Unité décliné par structures et par
rubriques.
a) Budget et PMT de la fonction S :
- Acteurs impliqués : R, S et RHU/Aval


 Plan des effectifs (Départs/Recrutements)
 Besoins organigramme de l’Unité
 Norme de la masse salariale RHU/Aval.
 Prévisions de salaires et charges patronales valorisées.
 Prévisions AFC, STC et gratification médailles.
 Liste du nombre prévisionnel d’agents concernés par les loyers et charges locatives.
- Fournitures consommées : (non régies par une norme) : Produits sociaux (articles de
literie, ….), outillage médical et produits pharmaceutiques (inter- unités OSL).
- Prestations de services :
 consultations médicales spécialisées (inter- unités OSL).
b) Budget de fonctionnements de la structure S :
 Entretiens et réparations matériels centre médical (inter- unités OSL).
 Nombre des missions par destinations.
Acteur /
Intervenant
RHU/Av
al, Dép.R Plan des effectifs (départs/recrutements)
et Dép.S
mois pour N et N+1) et PMT (de N+2 à N+5) :
 Salaires, charges patronales, AFC, STC et Dép. F Pour prise en compte dans le budget
gratification médailles valorisées. trésorerie .
 Fournitures consommées en quantités, non Dép. M
gérée en stock et non régie par une norme Pour compléter budget achat M
 Outillage médical et produits Dép. F (annexe).
pharmaceutiques valorisés Pour prise en compte dans le budget
Dép. S  Prestations services valorisées Dép. F des charges (inter- unités OSL).
(Entretiens et réparations matériels et Pour prise en compte dans le budget
consultations médicales spécialisées) des charges (inter- unités OSL).
 Nombre des missions de S par destinations. Dép. M Etat des missions détaillé (annexe).
 Liste du nombre prévisionnel d’enfants des
bases de SONATRACH concernés par le Dép. M Liste nominative .
 Liste du nombre prévisionnel d’agents Dép. M Liste nominative.
concernés par les loyers et charges locatives
7) Budget élaboré par le Département du département technique (T)

Objectif : Le budget du département technique a pour objectif d’élaborer les prévisions de
consommations des matières et fournitures et de prestations de services nécessaires dans le
cadre du respect des normes réglementaires pour la bonne exploitation de l’appareil de
production.
a) Budget et PMT de la fonction technique:
- Acteurs impliqués : T, G, P, A et M unité.
- Informations exploitées (input):
 Normes réglementaires
 Planning des visites réglementées
- Prévisions de consommation des matières et fournitures:
 Produits chimiques

 Gaz industriels
 Consommables (pour système DCS, laboratoire)
 Petits outillages
- Prévisions de prestations de services :
 Contrôle technique réglementaire
 Contrôle destructif et non destructif (test ultrason, radiographie, ressayage, ….)
 Expertise pour les dérogations APV/APG
 Etudes diverses
 Mise à jour du système DCS (logiciels, formations, ….)
b) Budget et PMT de fonctionnement de la structure T :
- Fournitures consommées (non régies par une norme) : produits sociaux, outillages de
laboratoire et inspection
- Nombre des missions par destinations.
Acteur /
Intervenant
Elaboration et transmission des prévisions quantitatives
PA (par mois pour N et N+1) et PMT (de N+2 à N+5)
Pour prise en compte dans le
 Matières et fournitures gérées et non gérées en
budget achat A (annexe)
stock
Dép. A Pour compléter budget achat
 Matières et fournitures pour fonctionnements
M (annexe)
Dép. T non régies par une norme, non gérées en
Dép. M
stock
Elaboration et transmission des prévisions valorisées de
budget trésorerie
prestation de services pour PA (par mois pour N et N+1)
Dép. F (annexe)
et PMT (de N+2 à N+5)
Etat des missions détaillé
Nombre des missions de T par destinations
Dép. M (annexe)
8) Budget élaboré par le Département de sécurité industrielle I

Objectif : Le budget du département sécurité industrielle a pour objectif d’élaborer les prévisions
de consommations des matières et fournitures et de prestations de services nécessaires à la
sécurisation de l’Unité et de minimiser les risques liés à l’utilisation des moyens matériels
(outillages, installations technique et matériels roulants).
a) Budget et PMT de la fonction:
- Acteurs impliqués : I et toutes les structures de l’Unité.
 Plan HSE
 Manuel EPI (Equipement de Protection Individuelle)
 Recommandations issues des audits
- Prévisions de consommation des matières et fournitures:
 produits chimiques
 gaz industriels
 PDR (pour matériels de sécurité)
 Outillages de sécurité
 EPI spécifiques à la sécurité industriel non régis par le manuel.
 Gestion des déchets
 Redevance ARPT,
 Réparation des radios.
 Cadastre des sites et sols pollués
 Etalonnage/calibrage
b) Budget et PMT de fonctionnements de la structure :

- Fournitures consommées (non régies par une norme) : Produits sociaux, consommations de
fournitures.
Acteur / Intervenant Action / Description Destinataire Observation / support
I, HSE/AVL, toutes
Plan HSE et Recommandations issues des audits
les structures
quantitatives PA (par mois pour N et N+1) et PMT
Pour prise en compte
(de N+2 à N+5)
dans le budget achat A
 Matières et fournitures gérées et non
Dép. A (annexe)
gérées en stock
 Matières et fournitures pour
Dép. M Pour compléter budget
fonctionnements non régies par une
Dép. I achat M (annexe)
norme, non gérées en stock
Dép. F budget trésorerie
valorisées de prestation de services pour PA (par
(Annexe)
mois pour N et N+1) et PMT (de N+2 à N+5)
Dép. M Etat des missions détaillé
Nombre des missions de I par destinations
(annexe )
9) Budget élaboré par le Département Travaux Neufs W

Objectif : budget exprimant les prévisions de prestations de services et consommations de
fournitures nécessaires pour la prise en charge des programmes d’investissements qu’ils
soient liés ou non liés à la production (ILP ou INLP).
a) Budget et PMT de la fonction travaux neufs :
- Acteurs impliqués : W et toutes les structures de l’Unité.
 Listing des investissements inscrit au Plan annuel et PMTE impliquant W.
 Planning des arrêts de maintenance
 Conventions (barème des prix, objet de la/les conventions)
 Mise à disposition de personnel dans le cadre des conventions
 Expertise et contrôle en génie civil dans le cadre des conventions et contrats
 Locations (moyens de transport, de levage et de manutention)
 Etudes de génie civil.
b) Budget et PMT de fonctionnements de la structure W :
- Fournitures consommées (non régies par une norme) : Produits sociaux, consommations
de fournitures (outillages, appareils de mesure et consommables spécifiques).
Acteur /
Intervenant
Action/ Description Destinataire Observation/support
Toutes les
Listing des investissements inscrit au Plan annuel et PMTE impliquant
structures
W
de l’Unité
- Elaboration et transmission des prévisions PA (par mois pour N et Dép. M Pour compléter
N+1) et PMT (de N+2 à N+5) des consommations de matières et et/ou Dép. budget achat M
fournitures pour fonctionnement non régies par une norme et non A et/ou A (annexe )
gérées en stock (prévisions quantitatives)
Dép. W Dép. F Pour intégration
- Elaboration et transmission des prévisions valorisées de prestation
dans le budget de
de services pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5)
trésorerie
- Nombre des missions de W par destinations Dép. M Etat des missions
détaillé (annexe)

10) Budget élaboré par le Département Système d’Information et de Gestion (SIG)

Objectif : le budget du département système d’information et de gestion a pour objectif de
déterminer les prévisions en matières et fournitures et prestations permettant à la
structure de réaliser ses missions (INF-ORG-QHSE).
a) Budget et PMT liés aux fonctions
- Acteurs impliqués : SIG et toutes les structures de l’Unité.
 Prévisions quantitatives des consommations de fournitures et consommables
informatiques des structures de l’Unité non régies par une norme
 Les normes de consommations quantitatives en fournitures et consommables
informatiques
 QHSE (certification, ….)
- Prévisions quantitatives consolidées des consommations de fournitures et consommables
informatiques régies et non régies par une norme et gérées en stock.
- Prévisions quantitatives consolidées des consommations de fournitures et consommables
informatiques non régies par une norme et non gérées en stock.
- Expression des besoins de prestations services à transmettre à la direction ISI (mises à
jour,…….).
 Les frais de télécommunications
 Réparations et maintenances des matériels et équipements informatiques et
télécommunications.
 Documentations (Papiers ou électroniques)
b) Budget et PMT de fonctionnement de la structure:
- Fournitures consommées (non régie par une norme): petit outillages, produits
sociaux,…………
- Nombre des missions par destinations.
Acteur /
Intervenant
Toutes les Prévisions quantitatives des consommations de fournitures et SIG
structures consommables informatiques non régies par une norme
Elaboration et transmission des prévisions PA (par mois pour N
et N+1) et PMT (de N+2 à N+5)
 Prévisions consolidées Unité consommations de
fournitures et consommables informatiques régies et Pour compléter budget
non régies par une norme gérées en stock Dép. M achat M (annexe) et
(prévisions quantitatives) valoriser les consommations
 Prévisions consolidées Unité consommations de
fournitures et consommables informatiques non
régies par une norme et non gérées en stock
(prévisions quantitatives) Dép. M Pour compléter budget
SIG
 Prévisions de consommations de matières et achat
fournitures pour fonctionnement non régies par
une norme et non gérées en stock (prévisions Pour compléter budget
quantitatives) Dép. M achat
Elaboration et transmission des prévisions valorisées de Pour intégration dans le

prestation de services pour PA (par mois pour N et N+1) et budget de trésorerie
PMT (de N+2 à N+5) Dép. F Annexe
Nombre des missions par destinations Dép. M Etat des missions détaillé

11) Budget élaboré par le département Passation des Marchés :

Objectif : Le budget du département passation des marches a pour objectif d’élaborer,
principalement, les prévisions en matières et fournitures et prestations de services induites
par le processus de passation des marchés de l’Unité.
a) Budget et PMT de la fonction passation des marchés:
- Acteurs impliqués : Département PM et toutes les structures de l’Unité
- informations exploitées (input) :
 plan de passation de marchés par Structure
-Informations (output)
 Prévisions de prestations de services : liées principalement à la publication
des appels d’offres
b) Budget de fonctionnement et PMT de la structure PM :
- Fournitures consommées (non régies par une normes) : Produits sociaux,
-Prestations de services : Nombre des missions par destinations.
c) Prévisions de recettes liées aux retraits des cahiers de charges.
Acteur /
Intervenant
Toutes les Dép. PM
structures Plan de passation de marchés
de l’Unité
Pour intégration dans
Elaboration des prévisions valorisées de prestation de services pour
Dép. F le budget de trésorerie
Annexe.
Elaboration des prévisions consolidées de recettes liées aux retraits des
Dép. F Pour prise en compte
cahiers de charges.
dans les prévisions de
Dép. PM
produits d’exploitation.
Elaboration et transmission des prévisions PA (par mois pour N et
N+1) et PMT (de N+2 à N+5) de consommation de fournitures non
Dép. M Pour compléter budget
régies par une norme, non gérées en stock (prévisions quantitatives)
achat M (annexe 2)
Elaboration et transmission des prévisions quantitatives de missions
Dép. M Etat des missions
pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5)
détaillé (annexe 3)
12) Budget élaboré par la Direction de l’Unité, D*E et D*S :

Objectif : budget exprimant les prévisions de consommations de fournitures et de services liées aux
postes, pour un fonctionnement normal.
- Acteurs impliqués : Directeur, Sous directeur Exploitation et Sous directeur Personnel
Budget de fonctionnement et PMT :

- Fournitures consommées (non régie par une norme) : Produits sociaux, consommation de
fournitures diverses et fournitures de bureaux,
Acteur /
Intervenant
Elaboration et transmission des prévisions de
consommations fournitures pour fonctionnement non
Dép. M Pour compléter budget achat
D/Unité régies par une norme et non gérées en stock (prévisions
(annexe) et valoriser les
D*E quantitatives) PA (par mois pour N et N+1) et PMT (de N+2
consommations
D*S à N+5)
Dép. M Etat des missions détaillé (annexe)
Nombre des missions par destinations

13) Budget élaboré par l’Assistant Sûreté Interne ASI

Objectif : budget exprimant les prévisions de consommations de fournitures et prestations de
services, dans le cadre de l’accomplissement des missions de cette Structure.
a) Budget et PMT de la fonction
- Acteurs impliqués : toutes les structures
Nombre de personnel et sous-traitants ouvrant droit à l’accès aux différentes zones
(port, zones industrielles, …)
- Prévisions de consommation des fournitures:
 Ports badges
 Badges
 Confection badges –impression- (interne et externe)
 Contrat gardiennage
 Escorte
b) Budget de fonctionnements et PMT:
- Fournitures consommées (non régie par une norme) : Produits sociaux,
consommation de fournitures diverses et fournitures de bureaux.
Acteur /
Intervenant
Toutes les Nombre de personnel et sous traitants ouvrant droit à
ASI
structures l’accès aux différentes zones
Elaboration et transmission des prévisions PA (par mois
pour N et N+1) et PMT (de N+2 à N+5) de consommation Dép. M Pour compléter budget achat
de fournitures non gérées en stock (prévisions (annexe) et valoriser les
quantitatives consommations
Elaboration et transmission des prévisions de Pour compléter budget achat

consommations fournitures pour fonctionnement non Dép. M (annexe) et valoriser les
régies par une norme et non gérées en stock (prévisions consommations
ASI quantitatives) PA (par mois pour N et N+1) et PMT (de
N+2 à N+5)
Elaboration et transmission des prévisions valorisées de Pour intégration dans le

prestation de services pour PA (par mois pour N et N+1) Dép. F budget de trésorerie
et PMT (de N+2 à N+5) Annexe
Nombre des missions par destinations Dép. M Etat des missions détaillé
(annexe)
14) Budget élaboré par le service relation de travail RT

services relatives au maintien du climat socioprofessionnel au sein de l’Unité.
a) Budget de fonctionnements PA et PMT:
- Fournitures consommées (non régies par une norme) : Produits sociaux,
consommation de fournitures diverses et fournitures de bureaux.

Acteur /
Intervenant Action / Description Destinataire Observation / support
Elaboration et transmission des prévisions de

Pour compléter budget achat
consommations en fournitures pour fonctionnement non
Dép. M (annexe) et valoriser les
régies par une norme et non gérées en stock (prévisions
consommations
RT quantitatives) PA (par mois pour N et N+1) et PMT (de
N+2 à N+5)
Dép. M Etat des missions détaillé
Nombre des missions par destinations
(annexe)
15) Budget élaboré par le conseil syndical

services, dans le cadre de l’accomplissement des missions du conseil syndical.
a) Budget de fonctionnements PA et PMT:
- Fournitures consommées (non régies par une norme) : Produits sociaux, consommation
de fournitures diverses.
Acteur /
Intervenant
Conseil Elaboration et transmission des prévisions de
syndical consommations en fournitures pour fonctionnement non
régies par une norme gérées et non gérées en stock Pour compléter budget achat
(prévisions quantitatives) PA (par mois pour N et N+1) et Dép. M (annexe) et valoriser les
PMT (de N+2 à N+5) consommations
Nombre des missions par destinations Dép. M Etat des missions détaillé (annexe)
16) Budget élaboré par le Département Finances :

Objectif : Le budget élaboré par le département finances a pour objectif de déterminer pour
l’ensemble de l’Unité, essentiellement, les prévisions des:
 Impôts et taxes,
 Assurances,
 Dotations aux amortissements,
 Frais bancaires
 Prestations de services prévues par Finances.
a) Budget et PMT élaboré par finances:

- Acteurs impliqués : Toutes les structures de l’Unité et autres structures AVAL
(DAG, FIN, DRIZ………….)
 Fichier investissement et le plan d’investissement Unité (pour le calcul des
amortissements)
 Plan de production (taxe GN auto consommé, ..)
 Patrimoine à assurer (contrats d’assurances, plan d’investissement et valeurs des
stocks)
 Plan d’approvisionnement
 Le nombre de contrats et montants prévisionnels à régler aux fournisseurs de
biens et services locaux et étrangers pour déterminer les services bancaires en
rapport avec les modes de paiements.
 Listing des véhicules légers et utilitaires réel

Prestations inter unité (frais de siège DG et AVAL, participation financière, …….)


Paiements pour compte (redevances téléphoniques, salaires des cadres

supérieurs, contrats groupés Aval,…)
 Plan des consommations valorisées (A et M)
 Prestations de services valorisées de toutes les structures
 Prix GN autoconsommé retenu comme norme
 Soldes des comptes comptables de dettes et créances par natures de dépenses.
 Prévisions d’impôt et taxes
 Prévisions d’assurances
 Prévisions dotations aux amortissements
 Prévisions des frais bancaires (commissions,……
 Prévisions des prestations inter-unités
 Valorisations des prévisions de GN autoconsommé
- Prévisions de prestations de services : honoraires avocats, commissaires-priseurs,
notaires.
b) Budget et PMT de fonctionnements de la structure F :
- Fournitures consommées (non régie par une norme) : produits sociaux, fournitures
diverses et fournitures de bureaux, ……………………..
Acteur / Intervenant Action / Description Destinataire Observation / support

Toutes les
structures de
Voir les informations exploitées (input)
l’Unité et autres Dép. F
structures AVAL
Elaboration et transmission des prévisions PA (par mois pour N et
N+1) et PMT (de N+2 à N+5) de consommation de fournitures non Pour compléter
régies par une norme, non gérées en stock (prévisions Dép. M budget achat M
quantitatives) (annexe)
Elaboration et transmission des prévisions quantitatives de missions Etat des missions

pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5) Dép. M détaillé (annexe)
Elaboration des prévisions valorisées de prestations de services

prévues par Dép. F pour PA (par mois pour N et N+1) et PMT (de
N+2 à N+5)
Elaboration des prévisions valorisées PA (par mois pour N et N+1) et

PMT (de N+2 à N+5) : Pour intégration
Dép. F
 Dotation aux amortissements dans le budget de
 Prévisions prestation inter-unité trésorerie
 Impôts et taxes Annexe
 Assurances
 Frais bancaires
 Valorisations des prévisions de GN autoconsommé
Consolidations des prévisions valorisées des charges (Unité) pour PA

(par mois pour N et N+1) et PMT (de N+2 à N+5)
Consolidations des prévisions valorisées des produits (Unité) pour

Elaboration des prévisions de trésorerie (Unité) pour PA (par mois

pour N et N+1) et PMT (de N+2 à N+5)

Bibliographie
Bibliographie 138
[01] J. Steffe. Cours UML. Ecole nationale des ingénieurs des travaux
agricoles de bordeaux, Mars 2005.
[02] S. Ghenima. Méthodes et outils pour la gestion des workflow-

Modélisation ontologique des processus pour l’analyse. Thèse de
Doctorat, Université Mouloud Mammeri de Tizi Ouzou, 2013.
[03] C. Lemaigre. Développement d'un éditeur graphique de workflow

générant automatiquement ses spécifications fonctionnelles.
Mémoire de licence. Université Catholique de Louvain. 2006-2007.
[04] N. Ramuz. Business Process Management, de la Théorie à la

Modélisation. Cours de Systèmes d’information I et II. Université de
Fribourg –Suisse, 2008.
[05] L. AUDIBERT. UML 2.0 . Support de cours, Institut Universitaire de

Technologie de Villetaneuse.
[06] M. Latifa & G. Nadia. Livre de la Pratique des systèmes

d’information : UML outil du génie logiciel. Edition Pages Blues, 2007.
[07] S. Hamri. Interopérabilité des Modèles de Workflow. Thèse de

Doctorat, Université Mentouri de Constantine.
[08] G. Zacharewicz. Un Environnement G-DEVS/HLA - Application à la

Modélisation et Simulation Distribuée de WORKFLOW. Thèse de
Doctorat, Université Paul Cézanne Aix-Marseille-III, 2006
[09] B. Dalila & K. Zahra. Réalisation d’un outil de modélisation workflow

des processus coopératifs – utilisation des diagrammes d’activités
UML. Mémoire de licence. Université des Sciences et de la
Technologie, 2008.
[10] M. TISSOT. Environnements d’édition de workflow. Rapport de Stage

effectué dans le cadre du projet Opéra – INRIA, Août 2000.
[11] H. Bersini. La programmation orientée objet, quatrième édition,

Eyrolles, Paris, 2009.
[12] J. Gabay, D. Gabay. UML 2 Analyse et conception, Dunod, Paris,

2008.
[13] Sylvain RAMPACEK. Sémantique, interactions et langages de

description des services web complexes. Thèse de Doctorat,
Université de Reims Champagne-Ardenne, 2006.

Bibliographie 139
,
[14] M.B. Juric B. Mathew, P. Sarang. BPEL pour les services web,
deuxième édition, Packt Publishing Ltd, janvier 2006.
[15] I. Chebbi and S. Tata. CoopFlow : a framework for inter-

organizational workflow cooperation. In Proceedings of International
Conference on Cooperative Information Systems, Agia Napa, Cyprus,
31 Oct-4 Nov 2005.
[16] Z. Maamar. Aperçu général sur la technologie des Workflows. Revue -

centre de recherches pour la défense valcartier, Canada. RIST
Vol.8N°02-1998.
[17] M. Baker. Workflow Meets Business Objects. In Proceedings of

OOPSLA'96 Workshop, Business Object Design and
ImplementationII: Business Objects as Distributed Application
Components - the enterprise solution, 1996.
[18] C.Mohan, G. Alonso, R. Günthör et M. Kamath. Exotica : A research

perspective on workflow management systems. Data Engineering,
18(1), Mars 1995.
[19] S. Paul, E. Park et J. Chair. Essential Requirements for a Workflow

Standard. In Proceedings of OOPSLA'97 Workshop, Business Object
Design and Implementation III: Patterns, Workflow, Components,
and the Web. Octobre 1997.
[20] Object Management Group. http://www.omg.org
[21] M.C. Schmidt. Building Workflow Business Objects. In Proceedings

of OOPSLA'98 Workshop, Business Object Design and
Implementation IV: From Business Objects to Complex Adaptive
System. Vancouver, Canada, Octobre 1998.
[22] H. Albrecht, M. Riebisch, T. Heverhagen et H. Liessmann. A Business

Object Framework Architecture. In Proceedings of OOPSLA'98
Workshop, Business Object Design and Implementation IV: From
Business Objects to Complex Adaptive System. Vancouver, Canada,
Octobre 1998.
[23] P. Hruby. Structuring Specification of Business Systems with UML

(with an Emphasis on Workflow Management Systems). In
Proceedings of OOPSLA'98 Workshop, Business Object Design and
Implementation IV: From Business Objects to Complex Adaptive
System. Vancouver, Canada, Octobre 1998.

Résumé
Le budget est un processus lourd et complexe à mettre en œuvre. Le premier rôle du

budget est de donner un cadre pour l’exercice à venir. La gestion budgétaire est un
mode de gestion qui englobe tous les aspects de l'activité de l'organisation qui
comprend une période de budgétisation (construction de l'ensemble cohérents de
prévisions chiffrées) puis une période de contrôle budgétaire. Les prévisions
budgétaires et leur planification au cours de toute l’année est une des parties
essentielles dans la gestion d’une entreprise industrielle. Elle permet aussi de donner
des délais courts aux demandes/commandes des clients et des agents de l’entreprise.
La gestion et le contrôle budgétaire au niveau de l’activité Sonatrach/AVAL n’adopte
pas de technique et de méthode automatique suffisante à la solution du processus
budgétaire. Les difficultés à ce niveau peuvent être vues classées en deux catégories :
des problèmes de gestion et des problèmes de contrôle. Le projet de l’automatisation de
la gestion et du contrôle budgétaire devient donc une nécessité prioritaire.
Notre objectif dans ce projet est la mise en place d'une solution informatique au
problème de la gestion et de contrôle des budgets au niveau de l'activité
Sonatrach/AVAL. Notre objectif final dans ce projet est l'adoption d'une approche
organisationnelle et méthodologique qui vise une automatisation de la gestion et du
contrôle des processus budgétaires et la mise en œuvre d'une solution généralisée pour
l'optimisation de la solution au niveau de l'activité AVAL. Une bonne prévision
budgétaire annuelle permet d’honorer les meilleures dépenses des clients et agents de
l’entreprise Sonatrach/AVAL. Les méthodes de prise en charge des flux utilisées seront
UML et Workflow, les outils de validation des modèles de conception seront
l’utilisation du Logiciel MagicDraw pour la génération des fichiers BPEL.
Mots-clés :
Modèle; Système D’information; UML; Workflow; Processus Métier; BPEL; Modélisation; Validation;
Représentation Relationnelle; Activité Budgétaire; Sonatrach/AVAL.

TH4211 PDF

Î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

TH4211 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

‫الجمه ـ ــورية الجزائريـ ـة الديمقراطي ـ ـة الشعبي ـ ـة‬

République Algérienne Démocratique et Populaire

‫كلي ـ ـة العـ ـلـ ـ ـوم الدقيقة والتطبيقية‬

Par : Mr. MENAD Si Mohamed Bekkai

CONCEPTION D’UN PROCESSUS DE

Mr. RAHMOUNI Mustapha Kamel, Professeur à l’Université d’Oran Président

Mr. Atmani Baghdad, Maître de Conférences à l’Université d’Oran Examinateur

Mme Nait Bahloul Safia, Maître de Conférences à l’Université d’Oran Encadreur

Je tiens tout d’abord à remercier Madame Nait Bahloul Safia, maître de

Je tiens aussi à remercier :

- Monsieur Rahmouni Mustapha Kamel, Professeur à l'université d’Oran de m’avoir

Je remercie également tout le personnel d’encadrement pédagogique et

Je remercie aussi tout le personnel du service des traitements au niveau de la

Je n'omettrais pas de remercier vivement tout le personnel de département

Enfin, un grand et chaleureux merci à ma femme pour sa patience et son

Mes défunts parents,

Résumé : Le budget est un processus lourd et complexe à mettre en œuvre. Le

Problématique et introduction générale …………..………………………….…………………….………..………..…… 01

Chapitre I : Modélisation d’un Système

3.6. Transitions ……….………………………………………………………………………………………….….………………………..…. 22

Chapitre III : Langage d’Exécution des processus métiers (BPEL)

Chapitre IV : Modélisation d’un processus métier par UML-Workflow

3.3.2. Description de la procédure de l’élaboration du budget PA et PMT de

5.2.17. Diagramme de processus métier de la fonction travaux neufs(W) …......…73

Chapitre V : Validation des diagrammes de processus Workflow

Chapitre VI : Architecture des processus métiers du système étudié et

Conclusion générale ……………………………………………………..……………………………………………………………...….….....98

Problématique et introduction générale

Le budget est un processus lourd et complexe à mettre en œuvre. Les entreprises

Le contrôle de gestion est un processus transversal destiné à aider les responsables

Conception d’un Processus de Développement par UML-WorkFlow

Conception d’un Processus de Développement par UML-WorkFlow

Outre l’introduction générale et la conclusion générale, ce mémoire est composé

Conception d’un Processus de Développement par UML-WorkFlow

contribution sur la modélisation statique UML (Diagramme de classes) , la modélisation

Conception d’un Processus de Développement par UML-WorkFlow

Modélisation d’un Système

2. L’approche orientée objet

Conception d’un Processus de Développement par UML-WorkFlow

2.2 Concepts importants

Figure 1.1- Représentation graphique d’une classe d’objets

b. Association : L’association décrit le lien statique entre plusieurs classes.

Figure 1.3- Exemple d’association réflexive

Conception d’un Processus de Développement par UML-WorkFlow

d. Composition : Lorsque que la suppression de l’objet agrégat mène à la suppression

Commande Ligne Commande

e. Héritage, Spécialisation, Généralisation et polymorphisme : L’héritage est un

Notation graphique Personne

Figure 1.6- Représentation graphique d’héritage entre la classe mère « Employé »

Conception d’un Processus de Développement par UML-WorkFlow

3.2 Les diagrammes UML

A. Diagrammes structurels ou diagrammes statiques (UML Structure)

B. Diagrammes comportementaux ou dynamiques (UML Behavior)

Conception d’un Processus de Développement par UML-WorkFlow

– diagramme de temps (Timing diagram)

3.3.2 Propriétés de classe

 Visibilité : Elle indique si l’attribut est public (+) ou privé (-)

3.3.3 Méthodes de classe

La syntaxe de définition d’un paramètre (<paramètre>) est la suivante :

[<direction>] <nom_paramètre>:<Type> [’[’<multiplicité>’]’] [=<valeur_par_défaut>]

La direction (<direction >) peut prendre l’une des valeurs suivante :

Conception d’un Processus de Développement par UML-WorkFlow

Les propriétés (<propriétés>) correspondent à des contraintes ou à des informations