Processus TT

© Réseau CRCF - Ministère de l'Éducation nationale -
http://crcf.ac-grenoble.fr
Centre de ressources comptabilité finance
Lycée Emmanuel Mounier

6 avenue Marcelin Berthelot – 38029 Grenoble CEDEX 2
site web : http://crcf.ac-grenoble.fr/
LA MODELISATION DES PROCESSUS

Jacques Sornet – Membre du CRCF
SOMMAIRE
A – L’étude des processus

B – Les approches MERISE
C – Le symbolisme UML
D – Les diagrammes SADT
La modélisation des processus – J. Sornet © CRCF Page : 1/ 30

A - L’ETUDE DES PROCESSUS
1 – La notion de processus.
Un processus de production se définit comme une succession d’activités transformant d es

ressources et créant une valeur pouvant satisfaire un client :
- c’est un processus principal, opérationnel ou métier s’il satisfait un client externe ;
- c’est un processus de support ou de soutien s’il sert un client interne à l’organisation.
Le processus est généralement transversal (il traverse des services ou des départements de
l’entreprise).
L’activité d’une organisation peut, dans son ensemble, être décrite par ses processus.
Le processus est un système organisé en fonction d’un but qui peut être décomposé en sous-
processus.
2 – Les processus et l’information.
Les activités de l’entreprise sont toutes déclenchées et contrôlées grâce à l’information, de

la réception d’une commande à l’encaissement de la facture correspondante.
Le système d’information est le reflet et le support de l’activité réelle de l’entreprise : système

d’information et système de production sont liés.
Processus
phy sique
Processus de
traitement de
l’information
L’étude des processus de traitement de l’information est donc à l’image des processus
physiques et elle permet de comprendre le système productif. Les méthodes élaborées pour
décrire le système d’information permettent de schématiser la production.
3 – La démarche d’étude du système d’information.
L’étude d’un système d’information est une démarche itérative qui nécessite la modélisation
du réel (un modèle est une représentation de la réalité, qui en reprend l’essentiel en écartant
des détails secondaires).
Le formalisme utilisé pour modéliser le système n’est pas neutre :

- il guide le raisonnement ;
- il permet un dialogue précis entre spécialiste et utilisateur (s’il n’est pas trop technique) ;
- il favorise la continuité des projets et la communication (s’il correspond à une méthode
standardisée et connue).
Exemples : formalismes MERISE (France), SADT (USA), UML (International).
L’étude des processus de traitements de l’information apporte une vision dynamique du

système et complète la modélisation statique des données.
La modélisation d’un processus informationnel repose très généralement sur trois éléments :
- des informations (ce que le processus traite ou véhicule par ses flux);

- des acteurs (personnes, unités organisationnelles ou lieux qui traitent les informations);
- des traitements de l’information (les actions de transformation de l’information).
Les enchaînements flux – traitements sont représentés par des diagrammes (diagramme de
flux, diagramme de circulation des informations, diagramme d’enchaînement des
traitements, … ).
Les diagrammes peuvent être présentés de différentes façons, l’essentiel étant qu’ils
montrent clairement comment l’organisation réagit pour traiter un événement interne ou
externe. Ce sont des supports d’analyse qui se précisent au fil de l’étude, et des visuels de
communication.
L’étude est menée par domaine : partie du système d’information qui regroupe un ensemble
cohérent de processus. Le découpage du système en domaines doit minimiser les échanges
entre domaines et il permet de scinder le problème à étudier et donc d’en simplifier l’étude.
Elle se concentre généralement sur les processus qui conditionnent l’activité de l’organisation,
notamment sur ses processus métiers et plus particulièrement sur les processus critiques ou
processus clés.

B - LES APPROCHES MERISE
MERISE est une méthode de conception des systèmes d’information de gestion développée
en France, où elle s’est imposée depuis les années 80, notamment pour les systèmes utilisant
des bases de données relationnelles.
1 – L’analyse des flux.
Dès son origine, la méthode MERISE préconise une approche analytique des traitements par
les flux d’information : recensement des acteurs et des flux, diagramme des flux et graphe
des flux.
1.1 – Matrice et diagramme des flux.
Les échanges de données ou de messages entre les acteurs du système d’ information sont
résumés dans une matrice ou un diagramme des flux (aussi appelé modèle conceptuel de
communications).
Exemple de matrice des flux :
Vers Service Service Service Client

De commercial expédition facturation
Service Commande
commercial
Service Avis Livraison à Bon de livraison
expédition expédition facturer
Service Facture
facturation
Client Réclamation Paiement
éventuelle
Exemple de diagramme des flux :

Service
Livraison à fact urer fact ura-
t ion
Commande
Service Service
commer- expédi-
Avis d’expédit ion Fact ure
cial t ion
Paiement
Bon de livraison
Client
Réclamat ion
Quand l’étude se place au niveau conceptuel (le niveau conceptuel s’intéresse à des
principes stables, indépendants de l’organisation pratique), les flux qui résultent de
l’organisation du travail ne doivent pas être retenus. On élimine notamment les flux internes
informants, qui ne font que transférer une information sans entraîner le déclenchement d’un

traitement (l’hypothèse est que ces flux sont potentiellement remplacés par une base de
données accessible aux acteurs).
Exemple de diagramme sans flux organisationnels informants (le transfert de l’avis

d’expédition ne déclenche aucun traitement, sa seule utilité est de mettre l’information
à disposition des commerciaux) :
Service
Livraison à fact urer fact ura-
Commande t ion
Service Service
commer- expédi-
cial t ion Fact ure
Réclamat ion Paiement
Bon de livraison
Client
1.2 – Graphe des flux et traitements.
A partir de la matrice ou du diagramme des flux, MERISE propose d’ordonner les flux dans un
graphe.
Exemple de graphe ordonné des flux conceptuels (la réclamation est supposée
provenir d’une erreur de livraison ou de facturation) :
Commande
Livraison à BL
fact urer
Fact ure
Réclamat ion
Paiement
Le graphe ordonné permet ensuite de positionner les traitements : le passage d’un flux à un
autre nécessite un traitement (non représenté s’il se situe à l’extérieur de l’entreprise, du

domaine ou du processus étudié) et chaque flux entrant doit être est traité. Un même
traitement n’apparaît qu’une fois dans le modèle.
Exemple de passage du graphe aux traitements :
Commande
Le même traitement
d’ex pédition conduit aux deux
Expédition flux résultants
Livraison à
BL
fact urer
I ci, en pointillés, les actions
menées hors entreprise (chez le
client), dont seules les
Facturation conséquences sont traitées.
Paiement Réclamat ion

Fact ure On ajoute les résultats
mettant fin aux
traitements.
Encaissement
Trait. réclamation
Paiement enregistré
Réclamation traitée
2 – La modélisation des traitements.
2.1 – Modélisation conceptuelle.
Un modèle de traitements peut se déduire du graphe des flux, en y associant des

échéances, des résultats qui ne constituent pas des flux et des règles de gestion. Un modèle
conceptuel des traitements est indépendant de l’organisation de l’entreprise.
Les traitements sont modélisés, avec MERISE, selon le formalisme des réseaux de Pétri (modèle
événements – résultats) :
- un ou plusieurs événements contribuent à déclencher un traitement ;
- un événement peut être l’arrivée d’un flux d’information ou celle d’une échéance ;
- les événements se combinent, selon une règle logique de synchronisation, pour déclencher
le traitement ;
- le traitement fournit un ou plusieurs résultats qui consistent en un flux ou un changement
d’état du système d’information ;
- l’un au moins des résultats arrête le traitement ;
- l’obtention d’un résultat peut être conditionnelle et soumise à une règle d’émission.
Remarque : règle de synchronisation et règle d’émission sont des règles de gestion,

parmi d’autres.
Exemple de modèle conceptuel de traitement des réclamations (en supposant que

l’approfondissement de l’analyse précédente montre que trois flux peuvent résulter du
traitement d’une réclamation : courrier, avoir ou colis) :

Réclama
t ion
arrivée
La « barre » de « justifié » est
une notation logique signifiant
« non justifié »
Traitement réclamation
Justifiée Justifiée
Fact. Livr.
Courrier
Avoir Expédit ion
envoyé
émis correct ive
demandée
Trois règles de base s’appliquent aux modèles de traitement :

- les actions déclenchées dans les mêmes conditions sont regroupées dans un même
traitement ;
- un traitement regroupe des actions se déroulant sans interruption (si une attente intervient
dans une suite d’actions, elles doivent être réparties entre deux traitements) ;
- l’obtention d’un résultat est un événement qui peut, en certains cas, contribuer au
déclenchement d’un autre traitement.
Exemple de modèle conceptuel de traitement de commandes prévoyant une rupture

de stock :
commande
reçue
SUIVI CLIENTS
toujours nouveau client
J+1
commande
commande client
en attente
à livrer enregistré
b
a c
(a ET b) OU (b ET c)
SERVIR COMMANDE
stock disponible
non oui
stock
BL émis
mis à jour

Remarque : le terme schéma est souvent utilisé pour désigner l’application concrète
d’un modèle MERISE. Ainsi, les exemples ci-dessus sont des modèles conceptuels des
traitements (MCT) ou des schémas conceptuels des traitements (SCT).
2.2 – La modélisation organisationnelle
Les modèles organisationnels des traitements sont similaires aux modèles conceptuels, mais ils
placent les traitements dans l’organisation pour répondre aux questions QUI, OU et QUAND.
Le modèle organisationnel prend donc en compte :

- des événements organisationnels, qui peuvent conduire à l’éclatement de certains
traitements (par exemple l’attente d’une certaine heure pour terminer un traitement) ;
- des modes et moyens de traitement (informatisé ou manuel, temps réel ou temps différé) ;
- une échelle de temps (pour tenir compte de délais de traitement) ;
- des postes de travail ou des lieux de traitement (un traitement peut être ainsi dupliqué sur
plusieurs lieux ou éclaté entre plusieurs postes) ;
- la liste des actions d’un traitement.
Exemples de modèle (ou schéma) organisationnel des traitements (MOT ou SOT) :
temps Service livraisons Service commercial Client
Commande
reçue Commande
Suivi client
J
Lendemain Toujours Nouveau
client
b Client
Commande c Commande enregist ré
en at t ent e à liv rer
a (a et b) ou (b et c)
Servir commande
J+1 St ock disponible
NON OU I
BL St ock
émis mis à
jour

2.3 – La modélisation analytique.
Les modèles de traitements analytiques MERISE permettent de confronter les modèles issus de
la conception des bases de données et ceux qui résultent de l’étude des traitements :
Conception des Conception des

données traitements
Schémas de données Schémas de traitements

(SCD, SR) (SCT, SOT)
Modèles analytiques
(rapprochement données –
traitements)
Un modèle de traitements analytique est obtenu en complétant un modèle de traitements

par des références aux données utilisées. Les ensembles de données utiles sont mentionnés à
droite de chaque traitement. Les actions qui les concernent (création, lecture, modification
ou suppression) sont indiquées grâce à la convention graphique suivante :
Trait ement Donnée Trait ement Donnée

s s
Créat ion de données Lect ure de données

exist antes
Trait ement Donnée

Trait ement Donnée
s
s
Suppression de
M odification (mise à jour)
données existantes
de données existantes
Exemple de modèle organisationnel des traitements analytique (MOTA) :

temps Service livraisons Service commercial Client
Commande
reçue Commande
Toujours
Client
Suivi client
J Commande
Lendemain Toujours Nouveau
client
Client
Si nouv eau client

b Client
Commande c Commande enregist ré
en at t ent e à liv rer
a (a et b) ou (b et c)
Servir commande St ock
J+1 St ock disponible Commande
NON OU I
BL St ock
émis mis à
jour
L’état de la commande (à livrer, en attente, livrée) est supposé être enregistré dans
une base de données. Il est alors redondant de déclencher le service des commandes
par des événements « commande à livrer » et « commande en attente », puisque ces
informations peuvent être lues dans la base. Certains auteurs proposeraient de
déclencher le traitement à partir de la seule échéance.
3 – L’approche systémique par les activités.
La méthode MERISE a été mise à jour dans les années 90 pour compléter la modélisation
d’origine, pour répondre aux besoins des nouvelles architectures de systèmes et pour
l’harmoniser avec différents travaux internationaux. En ce qui concerne les traitements,
MERISE /2 introduit une approche systémique par les activités, qui se définissent
progressivement à partir d’un modèle de contexte.
3.1 – Le modèle de contexte.
Le modèle de contexte représente les flux conceptuels échangés entre un domaine d’étude
et son environnement, constitué d’acteurs externes et d’autres domaines de l’entreprise
appelés domaines connexes.
Exemple de modèle de contexte (production et commercial sont des domaines

connexes) :

Données de gest ion
Domaine Domaine
production commercial
Sy nt hèse
Et at impay és client s
Fact ure
DOMAINE Fact ure client
Fournisseur Règlement
COMPTABLE Relance Client
Courrier lit ige
Demande d’informat ions Paiement
Ordres
Adminis- Déclarat ion
t rat ion Banque
Paiement t ax e Relev és
3.2 – Les modèles de flux.
A partir du modèle de contexte, le domaine étudié est décomposé successivement en

activités de plus en plus détaillées. On obtient :
- un modèle (ou diagramme) des flux conceptuel de niveau 1, ou modèle d’activités, qui
met en évidence les macro-activités du domaine (par exemple des processus) et leurs
échanges de flux ;
- un modèle (ou diagramme) des flux conceptuel de niveau 2, où chaque activité est
détaillée ;
- si nécessaire d’autres modèles, de plus en plus précis, jusqu’au niveau de l’opération
conceptuelle de traitement.
Exemple de modèle des flux de niveau 1(modèle d’activités) :
Données de gest ion

Domaine DOMAI NE COMPTABLE Domaine
production commercial
Sy nt hèse Suivi production
Et at impay és client s
Suivi commercial
Fact ure Fact ure client Client

Fournisseur Règlement Facturation Relance
Paiement
Courrier lit ige
Demande d’informat ions

Gestion fiscale
Ordres
Adminis- Déclarat ion Banque
t rat ion
Paiement t ax e Gestion trésorerie
Relev és
Les modèles de flux successifs aboutissent à un ensemble de traitements qui sont modélisés,
ensuite, dans des schémas similaires à ceux du §2 (MCT, MOT, MOTA).

4 – La complémentarité des approches.
Approche Approche
analytique (flux, systémique
graphes, (contexte,
opérations) activités,
opérations)
MCT Données
(SCD)
MOT MCTA
MOTA
APPLICATION
L’entreprise GENOUMOU fabrique des prothèses médicales sur mesure. Sa clientèle est
essentiellement constituée d'établissements de soin et la réalisation d'une prothèse se
déroule comme suit :
- le chirurgien prend date par téléphone pour une prothèse (réservation au planning de
GENOUMOU);
- dans les 15 jours, un courrier spécifie cette prothèse et confirme la date de besoin;
- le service "planning" la place définitivement et lance la fabrication. Il transmet sa décision
au commercial qui confirme par courrier au chirurgien en précisant l e prix de la prothèse;
- la prothèse produite est envoyée au service stockage expédition par la fabrication avec
une fiche descriptive mentionnant la date client;
- à la date prévue, la prothèse est expédiée et une copie du bon d'expédition est transmise
au service facturation qui facture à l'établissement du chirurgien;
- l'établissement règle la prothèse dans les 90 jours et le dossier est classé;
- faute de règlement dans les délais, une lettre de rappel est envoyée;
- si la prothèse ne convient pas, le chirurgien renvoie un courrier avec la prothèse.
GENOUMOU planifie les corrections en urgence, selon la procédure usuelle et sans
supplément de prix.
TRAVAIL A FAIRE
1 – Tracer le diagramme des flux.

2 – Etablir le graphe des flux.
4 – Situer les traitements potentiels sur le graphe.
5 – Recenser les événements et résultats ne constituant pas des flux (changements d’état du
système, contingence temporelle).
6 - Tracer le schéma conceptuel des traitements.
7 – Tracer le schéma organisationnel des traitements.

ELEMENTS DE CORRIGE
1 - Diagramme des flux
1 0 - re to u r
1 - p ris e d e d a te
CH IR U R GIEN 2 - co n firm a tio n /s p é cif. PL AN N IN G
9 - ra p p e l
1 1 - u rg e n ce
3 - la n ce m e n t
5 - d e s crip tif
6 - e x p é d itio n
ETAB L ISSEM EN T
FAB R ICATION 3 - d é cis io n
8 - rè g le -
7 - fa ctu re
m ent
STOCKAGE
FACTU R ATION
6 - co p ie b o n
COM M ER CIAL
4 - p rix e t co n firm a tio n
GENOUMOU

2 –Graphe des flux.
1
3D
3L
4
5
6F 6E
10
8 9 1
2
4 – Situer les traitements potentiels sur le graphe.
3L
3D
5
4
6F 6E
10
8 9

5 – Evénements et résultats ne constituant pas des flux (changements d’état du système,
contingence temporelle).
Fabrication réservée (état).

Prothèse fabriquée (état).
Prothèse stockée (état).
Date client arrivée (CT).
Délai dépassé (CT).
Affaire close (état).

6 - Schéma conceptuel des traitements.
Prise
date
(1)
Réservation
Confir- Fab. Retour Le retour est traité

mation réservée (10) comme une
(2) b confirmation
a c
A et b ou c
Lancement
Suivi production
Regroupements
possibles (ex : Décision
Lance-
« production- ment transmise
stockage ») Prothèse fait (3) (3)
Fiche
fabr.
transmise
(5)
Confirmation
Stockage
Prix
Date Prothèse confirmé
arrivée stockée (4)
Opération séparée car

ET synchronisée à la « date
arrivée »
Expédition
Expéditi Bon exp.

on faite T ransmis
(6) (6)
Expédition et facturation
considérées comme
conceptuellement identiques en cas
Facturation
de retour
Retour Normal
Rien Délai Facture Règlement

dépassé envoyée arrivé (8)
(7)
ET ET
Relance Encaissement
Rappel Affaire
envoyé close
(9)

7 – Schéma organisationnel des traitements (MOT).
PLANNING PRODUCTION COMMERCIAL MAGASIN FACTURATION EXT
P rise
date (1)
Réservation
Retour Fab.
(10) b réservé Confirma
e tion (2)
a c
A et b ou c
Lancement
Lancem Décision
Confirmation
ent fait transmise
(3) (3)
Suivi
Prix
production confirmé
(4)
Fiche Prothèse
transmi fabr.
se (5)
Stock
age
Date Prothèse
arrivée stockée
ET
Expédition Facturation
Retour Normal
Expéditi Bon exp.
on faite T ransmis
Facture
(6) (6) Rien Délai envoyée
dépassé (7)
EXT ET
Relance
Rappel
envoyé
(9)
Règleme
nt arrivé
(8)
ET
Encaiss
ement
Affaire
close

C - LE SYMBOLISME UML
1 – UML et l’approche objets.
L’approche objet consiste à définir les objets et les classes composant un système et à les
gérer :
- un objet est une « entité » qui se définit par une identité, des états (les valeurs possibles de
ses propriétés) et un comportement ;
- une classe est une abstraction qui regroupe les objets ayant les mêmes attributs (ou
propriétés) et les mêmes comportements.
La programmation objets facilite la réutilisation de composants logiciels déjà réalisés, el le est

parfaitement adaptée à la construction de systèm es modulaires ou « fragmentés ». Le
premier langage de programmation « objets » date de 1967 (SIMULA), et il a été développé
pour permettre la simulation de processus.
L’approche objet est liée à la notion de processus, et elle a donné naissance à la norme de
langage UML (unified method language) en 1997, qui permet la modélisation des objets et
des systèmes. UML évolue régulièrement (UML 1.1 standardisée en 1997, puis UML 1.2 en 1998
… UML 1.5 en 2003, et UML 2.1.1 en 2008).
Le symbolisme UML se révèle notamment adapté à la représentation de toutes sortes de

processus.
UML est un langage formel universel qui permet la modélisation à un niveau d’abstraction
élevé, sans ambiguïté, et sous une forme com préhensible par des non spécialistes (bien que
ce langage soit particulièrement goûté des informaticiens) , ce qui favorise la
communication.
UML n’est pas en soit une méthode et ne propose pas de processus de développement,
contrairement à MERISE, c’est une norme de présentation qui induit toutefois une réflexion
(unified process – UP est une méthode en cours de standardisation et basée sur UML).
2 – La modélisation des processus.
Nous aborderons les deux diagrammes les plus synthétiques d’UML qui so nt les mieux adaptés
à la modélisation fonctionnelle des systèmes. D’autres, comme le diagramme de séquence,
sont surtout appropriés pour la description fine des actions ou des transactions en vue d’une
programmation des systèmes.
2.1 – Les notations de base d’UML.
Les modèles UML peuvent contenir des notes, des commentaires explicatifs et des contraintes
(entre accolades). Notes et contraintes sont éventuellement reliées aux éléments concernés
par des lignes pointillées.
Exemple :
Un employ é {Un employ é Employé

occupe un emploi n’occupe
qu’un emploi}
Commentaire (dans une note) Contrainte (ici dans une note concernant
une classe)

Un paquetage est un regroupement de plusieurs éléments de modélisation. Les paquetages
permettent de définir des sous-systèmes et de faire abstraction de leur contenu, quand c’est
nécessaire:
Exemple :
Ce cartouche
indique un
paquetage
Domaine comptable Le paquetage a

un nom (qui peut
être placé dans le
cartouche)
2.2 – Le diagramme des cas d’utilisation.
Le diagramme des cas d’utilisation (DCU) décrit l’interaction entre des acteurs et un
système ; c’est un moyen de résumer les besoins des utilisateurs du système. Plusieurs
diagrammes complémentaires peuvent être établis.
Les acteurs (internes, externes et systèmes informatiques) sont symbolisés par et les cas
d’utilisation sont brièvement décrits dans un ovale.
Une interaction acteur – système peut être précisée par une phrase ou une multiplicité (1 *).
Un cas d’utilisation (use case) correspond à une fonction métier ou un processus de

traitement qui peut se décliner en plusieurs scénarios de traitement détaillés. Son nom
comporte un verbe à l’infinitif.
Exemple de paquetage « recrutement final » correspondant à une partie des cas

d’utilisation d’un système de recrutement. Un prestataire exécute plusieurs
recherches, et une recherche est faite par un seul prestataire (1 *) :
Recrutement final
{Le 5 du mois}, en
considérant les
départs prév us et
Etablir le plan constatés
Direction de recrutement
1
ex écute
*
Rechercher
des candidats
lance Prestataire
Fournit une liste
Mener des
DRH entretiens
donne un choix
Contacter des
candidats
Service opérationnel

2.3 – Le diagramme d’activités.
Le diagramme d’activités (DA) permet de représenter le déroulement d’un processus par un

flot d’activités (le DA est un « workflow »).
Une activité est une succession d’actions représentée par Nom activité
. (le nom
comporte un verbe à l’infinitif).
Deux types de transition entre activités sont possibles :
A1 A3 A1
[condition1] [condition2]
A2 A4 A5 A1 A1
Transitions automatiques. Transition conditionnelle

(les conditions – « gardes » - sont entre crochets).
Une barre de synchronisation permet, si nécessaire, de préciser que plusieurs activités doivent
être lancées simultanément ou être toutes terminées avant de poursuivre le process us.
Les symboles et indiquent le début et la fin du diagramme (l’arrivée sur un « nœud »

final arrête toute activité, plusieurs nœuds finaux peuvent correspondre à autant de
situations finales différentes).
Exemple de développement du cas d’utilisation « Mener des entretiens » :
Conv oquer
Recev oir un
les
candidat
candidats
[Reste candidat]
Ev aluer
Classer
[Plus de candidat]
Les opérations de ce
Préparer Préparer diagramme concernent
liste de liste des la classe « candidat »
refus acceptés
Env oy er

Un diagramme d’activités peut être organisé dans des couloirs (travées) d’activités
correspondant chacun à un domaine de responsabilité.
Exemple de processus d’intégration des candidats à l’embauche choisis par

l’entreprise (cas d’utilisation « Contacter les candidats ») :
Service opérationnel DRH Direction Prestataire
La direct ion ret ient plus

de candidat s que Cont act er les
nécessaire en prévision candidat s
des défect ions. ret enus
Recevoir les
Effect uer réponses
dernier choix
Envoyer des Envoyer des

let tres refus
d’embauche
Recevoir les
réponses
Convoquer les
embauchés
Recevoir les
embauchés
I nt égrer
l’employé
Les objets utiles, créés, supprimés ou modifiés par une activité peuvent être mentionnés dans
le diagramme d’activités. Leur état est éventuellement précisé.
Exemple :

Service opérationnel DRH Direction Prestataire
La DRH consulte les

év aluations d’entretiens, Cont act er les
choisit et note les candidat s
candidats embauchés ret enus
Ev aluation
[Enregistrée] Recevoir les

Effect uer réponses
dernier choix
Envoyer des
Envoyer des
let tres
refus
d’embauche
Candidat
[Embauché]
… /…
3 – Exemple de modélisation
Application à la gestion de production.
 Production en continu :
Prévision Pilotage Suivi Trait ement

Gest ion Livraison
de vent es product ion product ion commande
st ockage
Gest ion des M at ières

approvisionnements Commande Liv raison
client client
[Passée] [Expédiée]
Commande Liv raison
fournisseur fournisseur
[Passée] [Reçue]
La continuité du flot de production en continu résulte, si l’on excepte les aléas de la chaîne
de production physique qui n’est pas détaillée ici, de la précision du système
d’information en ce qui concerne :
- la prévision des ventes, pour éviter des à-coups ou des stocks pléthoriques ;
- la gestion des approvisionnements (quantités, maîtrise des délais fournisseurs, … ).

 Production par séries (avec stockage partiel) :
[commandée]
[immédiate]
Prévision Pilotage Suivi Gest ion Trait ement Livraison
de vent es product ion product ion st ockage commande
[stockée] [Différée]
Gest ion des
approvisionnements Liv raison
client
M at ières
[Expédiée]
Liv raison
fournisseur
Commande
fournisseur Carnet de Commande
[Reçue] commandes client
[Passée]
[Passée]
[A jour]
L’efficacité du processus de production par séries avec anticipation de la demande dépend,

comme en production continue, d’une bonne prévision des ventes et de la gestion des
approvisionnements. S’y ajoute en ce cas :
- le pilotage de la production, qui détermine la taille des séries et leur lancement afin d’utiliser
au mieux l’appareil de production tout en respectant la demande ;
- les études, non prises en compte dans le schéma, qui définissent a priori les procédés et les
standards de fabrication (gammes, nomenclatures, temps standard) ;
- le suivi de production qui fournit, dans un contexte de fabrication complexifié par la
diversité des produits, des informations utiles à la régulation du système (taux de pannes
machines, temps réel de réglage, … ).
 Production à la commande :
Trait ement Pilotage Suivi Livraison

commande product ion product ion
Commande Gest ion des

client approvisionnements Liv raison
client
[Passée]
M at ières
[Ex pédiée]
Commande Liv raison
fournisseur fournisseur
[Passée] [Reçue]
La production sur commande de produits standardisés repose, comme la production par

séries, sur des études. Le pilotage de la production a ici une importance prim ordiale car il
conditionne le taux d’utilisation de l’appareil productif et, avec les approvisionnements, le
délai de production.
Remarque : l’activité « suivi de production » pourrait être détaillée pour faire ressortir
toutes les phases productives (succession d’opérations de gamme, passage d’un
atelier à l’autre, … ).

APPLICATION
(Texte inspiré d’une étude de cas de l’Institut d’Ingéniérie Informatique de Limoges)
L’entreprise étudiée est une fabrique de tuiles et le domaine à explorer est celui de la gestion
des moules servant à produire ces tuiles.
INTERVIEW DU DIRECTEUR TECHNIQUE
Pour fabriquer des tuiles, on utilise un mélange d’argile et de sable humidifié et malaxé qui
alimente les presses qui forment les tuiles. Viennent ensuite les étapes de séchage, de cuisson
et d’emballage puis de stockage.
Une presse peut fabriquer toutes sortes de tuiles car la forme de chaque tuile est donnée par
un jeu de moules interchangeables. Un jeu de moules comprend trois éléments :
- un moule inférieur fixe ;
- un moule supérieur monté sur la partie mobile de la presse ;
- une tête d’aspiration.
L’entreprise fabrique 200 modèles de tuiles avec seulement 4 presses.
Les jeux de moules sont stockés quand ils ne servent pas, et nous disposons de plusieurs jeux
de moules pour un même modèle de tuile. Les moules s’usent et doivent être contrôlés, et si
nécessaire réparés ou mis au rebut. De temps en temps, il faut étudier et réaliser de
nouveaux moules destinés à la fabrication d’un nouveau modèle de tuile.
La gestion et la fabrication des moules est confiée à l’atelier des moules, qui notamment
monte et démonte les moules sur les presses et assure leur stockage. Le bureau d’études
établit les plans des nouveaux moules. Ces deux services sont sous la responsabilité du
directeur technique, qui décide de la mise en fabrication de nouveaux modèles de moules
et demande au bureau d’études d’en réaliser les plans.
INTERVIEW DU RESPONSABLE DU BUREAU D’ETUDE
Le BE reçoit et traite les demandes du directeur technique. Il dessine ou modifie les plans des
moules et lui soumet pour validation avant de les transmettre au responsable de l’atelier des
moules.
INTERVIEW DU RESPONSABLE DE L’ATELIER DES MOULES
L’atelier comprend deux équipes.
L’équipe des monteurs monte, démonte les moules sur les presses et assure leur stockage
entre deux utilisations. Le responsable des monteurs reçoit un plan de fabrication du
responsable de fabrication, qui indique les changements de moules prévus. A partir de ce
document, il rédige des bons d’intervention nominatifs pour chaque monteur. Lors du
montage ou du démontage, le monteur note sur ce bon le temps passé et les informations
sur l’état du moule, puis il remet le bon à son responsable. Après le démontage, les moules
sont rangés dans le stock atelier. Le responsable des monteurs contrôle alors les moules et
décide de les mettre au rebut, de les faire réparer ou de demander la fabrication de
nouveaux moules. Il adresse les demandes de réparation ou de fabrication au responsable
de l’atelier des moules.
L’équipe usinage fabrique et répare les moules. Le responsable de l’équipe reçoit les
demandes du responsable de l’atelier des moules. Il demande au magasin de mécanique
générale de l’usine les pièces standard dont il a besoin (boulons, écrous, h uile de coupe). Il
rédige les bons de travaux de ses ouvriers. L’usinage peut commencer quand les pièces sont

arrivées et le bon de travail établi. Les bons sont retournés au responsable d’équipe en fin de
travail, avec mention des temps passés. Les moules terminés sont stockés dans l’atelier
d’usinage et le responsable des monteurs est prévenu de leur disponibilité.
La fabrication de nouveaux moules utilise des préformes fournies par les fonderies. Une
préforme est un bloc d’acier qui a approximativement la forme du moule souhaité. L’équipe
d’usinage lui donne sa forme définitive. Les préformes sont commandées aux fonderies par le
responsable de l’atelier des moules à l’aide d’un bon de commande accompagné des
plans des moules concernés. La fonderie confirme la date de livraison prévue, puis elle livre
les préformes qui sont réceptionnées par le responsable d’usinage. La fonderie envoie sa
facture au service comptable qui demande au responsable de l’atelier des moules de
confirmer la livraison puis paye le fournisseur.
Le diagramme des flux de la gestion des moules est le suivant :
17
bureau 4 fonderie
d'études 18
20 23
21
responsable
10 atelier moules
22
24 comptabilité
1 2 3 25
directeur resp.
technique fabrication
9
19 16
responsable responsable
usinage monteurs
13 14 6 7
ouvrier monteur
15 8
11 12
mécanique
générale
Désignations des flux (flux physiques en pointillés) :
1 - demande de plan 2 - proposit ion de plan

3 - plan accept é 4 - plan enregistré par BE
5 - plan de fabricat ion 6 - bon d'int ervention
7 - bon complét é 8 - st ockage (bon ent rée) moule
9 - demande de moule 10 - demande de réparat ion ou fabricat ion
11 - demande de pièce 12 - dést ockage (bon sort ie) pièce
13 - bon de t ravail 14 - bon de t ravail complété
15 - st ockage (bon ent rée) moule 16 - avis moule disponible
17 - commande préforme, plan 18 - confirmation
19 - récept ion (bon entrée) préforme 20 - fact ure
21 - fact ure à viser 22 - fact ure visée
23 - paiement 24 - demande d'ét at des moules

25 - valeur des moules
TRAVAIL A FAIRE
1 - établir le diagramme des cas d’utilisation mettant en évidence l’élaboration des plans, le
montage de moule, l’usinage des moules, l’approvisionnement en préformes, la facturation.
2 - Tracer le diagramme d’activités correspondant au cas « usinage des moules ».
ELEMENTS DE CORRIGE
1 – Diagramme des cas d’utilisation (en assimilant responsables et équipes) :
Gestion des moules
Valide
Elaborer des
demande plans
Direction
Réalise
plan
Monter un moule
BE
Planifie
Fournit Magasin
Resp. fab. Réalise

cont rôle
Lance
Usiner un moule
Fabrique
répare Responsable
st ocke at. moules
Equipe
Commande
montage
Approv isionner
préformes
Récept ionne
Cert ifie Equipe

Livre usinage
Facturer
Fact ure
Fournisseur

2 – Diagramme d’activités (usinage uniquement) :
EQUIPE USINAGE MAGASIN RESPONSABLE ATELIER M.
Et ablir
demande
Demander
pièces
Fournir
Rédiger bons
U siner et relever
t emps
St ocker
Prévenir
mont eur

D – LES DIAGRAMMES SADT
1 – L’objectif de SADT
 SADT (structured analysis and design technic) – IDEF (icam definition method) est une
méthode de description arborescente qui permet la spécification fonctionnelle de
systèmes complexes.
 SADT décrit les fonctions du système et les objets traités par ces fonctions :
- le niveau « 0 » représente le système dans sa globalité (diagramme de contexte) ;
- chaque niveau supplémentaire décompose le précédent ;
- sauf au niveau « 0 », chaque diagramme SADT comprend de 3 à 6 ou 7 éléments.
 On peut partir du niveau « 0 » et le décomposer (démarche descendante), ou définir

les éléments de plus bas niveau puis les agréger démarche ascendante).
Etc …
Niveau « 2 » Niveau « 2 »
Niveau « 1 »
Niveau
«0»
2 – Les diagrammes SADT
 Par leur simplicité, les diagrammes SADT sont un support de communication entre les
analystes, les utilisateurs gestionnaires et la hiérarchie.
 Chaque diagramme regroupe des boîtes, chaque boîte a un nom :

- les boîtes qui s’enchaînent sont placées en diagonale ;
- chaque boîte a des entrées, des sorties, des contrôles (contraintes) et des ressources
(mécanismes, moyens nécessaires) symbolisés par des flèches.

2.1 – L’actigramme
 Les boîtes d’un actigramme représentent des activités (leur nom commence par un
verbe) :
- les entrées sont des données ou des objets disponibles, à traiter ;
- les sorties sont des données ou objets créés ;
- les données de contrôle peuvent être les résultats d’une activité ;
- il y a au moins un contrôle qui déclenche l’activité et au moins un résultat en sortie ;
- une donnée qui sert aussi de contrôle est placée de préférence en contrôle.
Exemple d’actigramme (décomposition de l’action « convoquer les candidats ») :
Compt e
Consignes rendu DRH
List e de List e
candidat s Délai 24h
ret enue
Choisir les
candidats Procédures
Profil de List e validée

Let t re Valider
post e t ype M odèle
l’env oi
let tre
Logiciel Secrét ariat Courrier
Préparer
GRHX préparé
les courriers
Logiciel DRH Adresses Envois
GRHX mémorisés
Logiciel Service
GRHX courrier
2.2 – Le datagramme
 Les boîtes d’un datagramme représentent des données (leur nom désigne les
données) :
- les entrées sont des activités générant les données ;
- les sorties sont des activités utilisant les données ;
- les contrôles sont des activités dont le résultat influe sur la création ou l’utilisation des
données (les contrôles ont ici parfois peu de sens) ;
- les activités figurant dans le datagramme peuvent se situer à différents niveaux des
actigrammes.

Exemple d’actigramme (relatif à la convocation des candidats) :
Définir le
post e
Choisir les
candidat s Liste
retenue
Et ablir les
procédures
Liste
v alidée
Logiciel Secrét ariat
GRHX Valider l’envoi Préparer les Env ois
Logiciel DRH courriers Relancer les
GRHX mémorisés
Concevoir candidat s
let tre t ype
Modèle
lettre
Logiciel Service
GRHX courrier
Logiciel DRH
GRHX

Processus TT

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Processus TT

Загружено:

Авторское право:

Доступные форматы

© Réseau CRCF - Ministère de l'Éducation nationale -

Lycée Emmanuel Mounier

site web : http://crcf.ac-grenoble.fr/

LA MODELISATION DES PROCESSUS

A – L’étude des processus

La modélisation des processus – J. Sornet © CRCF Page : 1/ 30

Un processus de production se définit comme une succession d’activités transformant d es

2 – Les processus et l’information.

Les activités de l’entreprise sont toutes déclenchées et contrôlées grâce à l’information, de

Le système d’information est le reflet et le support de l’activité réelle de l’entreprise : système

3 – La démarche d’étude du système d’information.

Le formalisme utilisé pour modéliser le système n’est pas neutre :

Exemples : formalismes MERISE (France), SADT (USA), UML (International).

L’étude des processus de traitements de l’information apporte une vision dynamique du

La modélisation des processus – J. Sornet © CRCF Page : 2/ 30

La modélisation des processus – J. Sornet © CRCF Page : 3/ 30

1 – L’analyse des flux.

1.1 – Matrice et diagramme des flux.

Exemple de matrice des flux :

Vers Service Service Service Client

Exemple de diagramme des flux :

La modélisation des processus – J. Sornet © CRCF Page : 4/ 30

Exemple de diagramme sans flux organisationnels informants (le transfert de l’avis

1.2 – Graphe des flux et traitements.

La modélisation des processus – J. Sornet © CRCF Page : 5/ 30

Exemple de passage du graphe aux traitements :

Paiement Réclamat ion

2.1 – Modélisation conceptuelle.

Un modèle de traitements peut se déduire du graphe des flux, en y associant des

Remarque : règle de synchronisation et règle d’émission sont des règles de gestion,

Exemple de modèle conceptuel de traitement des réclamations (en supposant que

La modélisation des processus – J. Sornet © CRCF Page : 6/ 30

Trois règles de base s’appliquent aux modèles de traitement :

Exemple de modèle conceptuel de traitement de commandes prévoyant une rupture

toujours nouveau client

La modélisation des processus – J. Sornet © CRCF Page : 7/ 30

2.2 – La modélisation organisationnelle

Le modèle organisationnel prend donc en compte :

Exemples de modèle (ou schéma) organisationnel des traitements (MOT ou SOT) :

temps Service livraisons Service commercial Client

J+1 St ock disponible

La modélisation des processus – J. Sornet © CRCF Page : 8/ 30

Conception des Conception des

Schémas de données Schémas de traitements

Un modèle de traitements analytique est obtenu en complétant un modèle de traitements

Trait ement Donnée Trait ement Donnée

Créat ion de données Lect ure de données

Trait ement Donnée

Exemple de modèle organisationnel des traitements analytique (MOTA) :

La modélisation des processus – J. Sornet © CRCF Page : 9/ 30

Si nouv eau client

Servir commande St ock

J+1 St ock disponible Commande

3 – L’approche systémique par les activités.

3.1 – Le modèle de contexte.

Exemple de modèle de contexte (production et commercial sont des domaines

La modélisation des processus – J. Sornet © CRCF Page : 10/ 30

Demande d’informat ions Paiement

3.2 – Les modèles de flux.

A partir du modèle de contexte, le domaine étudié est décomposé successivement en

Exemple de modèle des flux de niveau 1(modèle d’activités) :

Données de gest ion

Sy nt hèse Suivi production

Fact ure Fact ure client Client