La formation sur l'analyse de processus et workflows, animée par Philippe Dornbusch, aborde la définition des processus, la méthode Merise et UML, ainsi que l'automatisation des workflows. Elle comprend des ateliers pratiques, des études de cas, et se concentre sur l'optimisation des processus dans le cadre du télétravail. Les participants apprendront à identifier clairement les attentes des clients et à analyser l'efficacité des activités pour améliorer la performance organisationnelle.

1. Bienvenue à la formation
Analyse de Processus et Workflow
1
Philippe DORNBUSCH
Responsable du service Projets RH & Management
Direction des Ressources Humaines du CA IDF

2. Le tour de table des participants à cette formation
2

3. 3
Tu me dis, j’oublie
Tu m’enseignes, je me souviens
Tu m’impliques, j’apprends
Benjamin Franklin, (1706-1790), écrivain, inventeur et homme politique américain
L’importance de la mise en pratique pendant cette formation

4. Programme de la formation
Introduction et Définition des processus
Atelier fil rouge : mise en pratique avec des études de cas concrets
Méthode d’Analyse des processus
Merise et son Modèle Conceptuel de Communication (MCC)
4
Le Workflow (automatisation des tâches du processus)
L’analyse logicielle avec UML (Unified Modeling Langage)
Devoir individuel puis corrigé du devoir

5. Organisation pratique de la journée 1
9h-9h30 Accueil des participants et tour de table
9h30 - 10h30 Définition et méthode d’analyse des processus
10h30 - 11h Pause
5
13h30 - 15h Définition d’un Workflow
11h – 12h30 Exercice d’analyse de processus : le télétravail
12h30 - 13h30 Pause déjeuner
15h - 15h30 Pause
15h30 - 17h Merise et le Modèle Conceptuel de Communication

6. Organisation pratique de la journée 2
9h00 - 10h30 Réalisation d’un MCC
10h30 - 11h Pause
6
13h30 - 15h Cas d’utilisation et diagramme de séquence
11h -12h30 L’analyse logicielle avec UML
12h30 - 13h30 Pause déjeuner
15h - 15h30 Pause
15h30 - 16h30 Le Quiz individuel
16h30 – 17h00 Correction du Quiz et Conclusion de la formation

7. 7
Introduction à la notion de processus

8. Définition d’un Processus
• Un processus est un ensemble d'activités corrélées ou en interaction qui utilise
des éléments d'entrée pour produire un résultat escompté. Ces éléments sont
soit des objets matériels (pouvant être perçus comme des flux par
la logistique à des fins d'évaluation) soit des informations, soit les deux.
8

9. Définition d’un Processus
• Il ne faut pas confondre « processus » avec
« procédure ».
• Le premier décrit les activités de l'entreprise
selon une vision transversale par rapport à
l'organisation de celle-ci, tandis que le second
explicite le "comment faire" dans cette
organisation.
• L'approche processus permet d'identifier et de
maîtriser les interfaces entre les différentes
activités.
9

10. Définition d’un Processus
• Le processus répond aux questions : QUOI
FAIRE ? POUR QUELLE VALEUR AJOUTÉE ?
• La procédure répond aux questions : COMMENT
FAIRE ? QUAND ? QUI ?
• Le mode opératoire répond de plus aux
questions : OÙ ? SELON QUEL PROCÉDÉ ?
• Le mode pilotage répond de plus à la question :
COMBIEN ?
10

11. Méthode d’analyse des processus
11

12. L'analyse des processus – les étapes
• Lorsqu'on veut optimiser ou transformer radicalement un
processus, on a besoin d'une méthode rigoureuse.
• L'analyse des processus est l'outil le mieux adapté à ces
deux tâches. En mode « transformation radicale », elle
aide à changer non seulement les façons de faire, mais
également les façons de voir, soit les paradigmes des
personnes concernées.
• En outre, cette méthode favorise la participation en
mettant à contribution des salariés de divers secteurs qui
travaillent en contact constant avec les acteurs du
processus (dans une démarche de type « expert », les
participants sont en vase clos sans interaction avec
l'environnement).
12

13. L'analyse des processus – les étapes
La méthode implique deux questions fondamentales, celle
de la pertinence et celle de l'efficacité des activités et des
étapes du processus. En d'autres mots:
• Faisons-nous les bonnes choses pour nos clients ?
• Les faisons-nous de la meilleure façon ?
13

14. Les résultats escomptés
• Processus redessinés, prêts à être implantés et qui
livrent un résultat conforme aux spécifications du
client.
• Processus qui améliorent la performance
organisationnelle sur 4 axes à la fois: client,
ressources humaines, ressources financières et
opérations.
• Recommandations concernant le nouveau processus
et description des impacts sur l'encadrement, les
gains et investissements financiers, la technologie,
les ressources humaines, etc.
14

15. Les conditions de succès
• S'assurer que les processus analysés sont
prioritaires ou liés aux orientations stratégiques.
• Dès le début de la démarche, s'associer en mode
concerté avec les instances syndicales.
• Faire preuve de transparence à toutes les étapes.
• Concevoir et appliquer une stratégie de
communication pour informer toute
l'organisation.
15

16. Les conditions de succès
• Être prêt à investir du temps, de l'énergie et des
ressources.
• Respecter les membres de l'équipe (liberté de
s'associer ou non aux recommandations).
• Confier à une ressource externe le soin
d'accompagner l'équipe (rigueur
méthodologique, apprentissage des outils et du
processus de changement organisationnel).
16

17. 17
Analyse d’un processus
Le Télétravail en entreprise

18. Le parcours du Télétravail
La demande du collaborateur
Le collaborateur enregistre sa
demande de télétravail à partir de
l’outil dédié (Téléflow)
1
Collaborateur du siège
3
La signature de l’avenant au contrat de
travail
Après accord du manager, le
collaborateur fournit les pièces
demandées par la DRH puis signe
son avenant
La décision du manager
Le manager organise une réunion
d’analyse de la demande avec le
collaborateur et décide (accord /
refus)
2 4
3
5
La récupération du matériel
Le collaborateur récupère le matériel
requis auprès de DOMS/IT
Le démarrage du télétravail
Le collaborateur installe le matériel
à son domicile et télétravaille le
moment venu

19. Le parcours du Télétravail
La demande du collaborateur1
Avant de faire sa demande, le collaborateur peut autoévaluer
ses aptitudes et ses motivations au télétravail à l’aide de la grille
disponible sur chorale NET
 Le collaborateur crée une demande à partir de Téléflow
La décision du manager2
 Le manager est prévenu par mail de la demande de
télétravail de son collaborateur
 Le manager organise un entretien (dans un délai de 30 jours
à compter de la réception du mail) avec son collaborateur pour
en apprécier l’éligibilité au télétravail. Il utilise la Grille d’éligibilité
au télétravail disponible sur chorale NET
 Le manager acte sa décision, en la motivant, sur Téléflow
(dans un délai de 60 jours à compter de l’entretien)
La signature de l’avenant au contrat de travail3
 Le collaborateur est prévenu par mail de la décision de son
manager
 En cas d’accord du manager, le collaborateur dépose dans
Téléflow une attestation sur l’honneur de la conformité de
l’installation électrique de son domicile et une attestation de
couverture Multi risques habitation intégrant la pratique du
télétravail. Des modèles et exemples sont disponibles sur
chorale NET
 La DRH contrôle la conformité des documents puis fait
parvenir au manager l’avenant en double exemplaire qui les
remet à son collaborateur
La récupération du matériel4
 DOMS annonce par mail au collaborateur que le matériel
requis est disponible
 Le collaborateur vient récupérer son matériel en suivant les
instructions de DOMS et signe une prise en charge.
Le démarrage du télétravail5
 Le collaborateur installe le matériel à son domicile en suivant
les indications du Guide Technique du Télétravail mis à disposition
sur chorale NET
 Le collaborateur peut commencer le télétravail à la date
convenue dans l’avenant
 Le collaborateur signe l’avenant. Il envoie à la DRH l’avenant
papier signé (nécessité juridique) et en dépose une copie dans
Téléflow. Il conserve le deuxième exemplaire

20. Pour le télétravailleur
• Préparer votre journée de télétravail en vous assurant d’avoir
tous les éléments nécessaires.
• Fixez-vous des objectifs et des livrables à réaliser au cours de
la journée.
• Fixez, avec votre manager, des plages de joignabilité.
• Les documents confidentiels doivent rester sur le lieu de
travail et ne doivent pas être emmenés au domicile
• Même si vous êtes en télétravail, vous avez l’obligation de
vous rendre au rendez-vous, réunions et formations durant
lesquels votre présence est impérative en décalant si besoin
votre journée de télétravail dans la même semaine, avec
accord de votre hiérarchie.
• Informez vos collègues que vous êtes en télétravail. Rappelez
que vous êtes joignable comme sur votre lieu de travail
habituel.
• Délimitez votre espace de travail à domicile
• Adoptez une bonne posture de travail
Pour le manager et l’équipe
• Favorisez les réunions d’équipe les jours où le télétravailleur
est présent.
• Quand la réunion a lieu un jour où il n’est pas présent,
n’oubliez pas de l’intégrer à distance.
• N’omettez pas le télétravailleur dans l’envoi de vos mails.
• Ayez le réflexe de solliciter le télétravailleur comme vous le
feriez quand il est présent au bureau et non un collègue parce
que lui est physiquement là.
• Même en dehors des locaux, le télétravailleur est joignable
aux heures habituelles et pas seulement en cas d’urgence.
Organiser le télétravail

21. Calendrier de déploiement par vagues successives de 50
collaborateurs
vague 1 : ouverture du Workflow des demandes aux collaborateurs le 18 avril –
validation Managers jusqu’au 5 Mai - Équipement de 50 collaborateurs au 1er juin
2017
vague 2 : validation Managers jusqu’au 19 Mai - Équipement de nouveaux
collaborateurs au 1er juillet 2017
vague 3 : validation Managers jusqu’au 18 Août - Équipement de nouveaux
collaborateurs au 1er octobre 2017
puis nouvelles vagues trimestrielles à compter de 2018 (janvier et juillet)

22. Les 4 étapes dans l’analyse des processus
22

23. Les 4 étapes de l'analyse des processus
• Élaborer le mandat de l'équipe
• Analyser le processus actuel
• Baliser
• Élaborer la nouvelle architecture du processus
23

24. Les 4 étapes de l'analyse des processus
1 - Élaborer le mandat de l'équipe
Après avoir reçu de la direction les grandes lignes de la
situation problématique, l'équipe de travail :
• identifie les frontières du ou des processus à analyser
• recueille les attentes des clients face aux résultats qui leur sont
livrés
• recueille les attentes des propriétaires du processus
concernant la performance
• élabore son mandat en précisant les résultats spécifiques du ou
des nouveaux processus ainsi que les valeurs sur lesquelles elle
s'appuiera tout au long du travail à accomplir.
• Le mandat est présenté pour approbation au comité de
direction et au gestionnaire concerné (généralement, les
membres de l'équipe font la présentation).
24

25. Les 4 étapes de l'analyse des processus
25
2 - Analyser le processus actuel
• L'équipe recueille sur le terrain les informations nécessaires
pour faire la cartographie du flux des processus étudiés
(ordinogramme).
• La cartographie est constamment validée par les gens du
terrain afin de s'assurer qu'on décrit la situation actuelle et
non ce qu'on souhaiterait avoir plus tard.
• Ce travail permet par la suite de faire l'analyse de la valeur
de chacune des étapes et d'établir par la même occasion une
série de constats objectifs sur l'efficacité du processus
analysé.
• On effectuera souvent en parallèle à la cartographie une
analyse financière sommaire basée sur les coûts d'obtention
de la qualité des résultats produits par les processus actuels.

26. Les 4 étapes de l'analyse des processus
26
2 - Analyser le
processus actuel

27. Les 4 étapes de l'analyse des processus
27
2 - Analyser le
processus actuel
La demande du collaborateur
Le collaborateur enregistre sa
demande de télétravail à partir de
l’outil dédié (Téléflow)
1
Collaborateur du siège
3
La signature de l’avenant au contrat de
travail
Après accord du manager, le
collaborateur fournit les pièces
demandées par la DRH puis signe
son avenant
La décision du manager
Le manager organise une réunion
d’analyse de la demande avec le
collaborateur et décide (accord /
refus)
2 4
3
5
La récupération du matériel
Le collaborateur récupère le matériel
requis auprès de DOMS/IT
Le démarrage du télétravail
Le collaborateur installe le matériel
à son domicile et télétravaille le
moment venu

28. Les 4 étapes de l'analyse des processus
28
3 – Baliser (ou benchmarker)
• Les constats résultant de l'analyse permettent
d'identifier des cibles de balisage. La direction est mise
à contribution pour aider l'équipe à établir des contacts
avec diverses entreprises.
• Par la suite l'équipe planifie et organise son balisage en
préparant une série de questions qui portent soit sur
les façons de faire ou les façons de voir (concepts) des
thèmes ciblés.
• À son retour, l'équipe fait le bilan de ses découvertes et
identifie les premières possibilités d'adaptation.

29. Les 4 étapes de l'analyse des processus
29
4 - Élaborer la nouvelle architecture du processus
• L'équipe précise le nouveau concept qui appuiera la nouvelle
architecture du processus.
• Ensuite, elle effectue une nouvelle cartographie en mettant
l'accent sur la pertinence de chacune des activités ou étapes
ainsi que sur la meilleure façon de l'exécuter.
À titre indicatif, le nouveau processus devrait viser les
barèmes suivants :
• au moins 65 % d'activités à valeur ajoutée,
• de 10 à 15 % d'activités de contrôle et de vérification,
• de 10 à 15 % d'activités de décision
• un maximum de 10 % de délai et de transport,
• et aucune activité inutile.

30. Les 4 étapes de l'analyse des processus
30
4 - Élaborer la nouvelle architecture du processus
• Une fois la cartographie terminée, l'équipe identifie les
impacts qu'aura la nouvelle architecture, particulièrement sur
l'encadrement, les ressources humaines et la technologie.
Elle précise également les gains et investissements requis.
• De nombreuses consultations sont effectuées auprès des
services de soutien pour valider ou raffiner certains éléments.
• Puis l'équipe élabore une série de recommandations pour
l'implantation éventuelle des nouveaux processus.
• Enfin, elle présente le fruit de son travail à l'équipe de
direction.
• La direction aura à décider quelles recommandations seront
retenues et implantées.

31. Un exemple d’analyse de processus (Mouvement québécois de la Qualité)
31

32. Un exemple d’analyse de processus
32
1 - Le mandat
Une organisation dans le domaine des
télécommunications au Québec veut revoir les
façons de faire de ses équipes techniques. Après
avoir compris le problème et les attentes de la
direction, l'équipe propose que le nouveau
processus permette entre autres de :
 résoudre 100 % des problèmes ne nécessitant pas
un déplacement lors de la prise d'appel
 éliminer 80 % du papier
 réduire les charges d'exploitation de 25 %

33. Un exemple d’analyse de processus
33
2 - L'analyse des processus actuel
Il s'est dégagé plusieurs constats de l'analyse
des processus :
 pas de calendrier de rendez-vous
 surutilisation et surmanipulation de papier
 qualité livrée non conforme aux attentes
 pas de communication entre les secteurs.

34. Un exemple d’analyse de processus
34
3 - Le balisage ou benchmarking
Le balisage a pour but d'apprendre des autres.
Les membres de l'équipe visitent 19 entreprises
au Québec, au Canada et aux États-Unis. Leurs
constatations :
 utilisation de nouvelles technologies (terminaux
à bord des véhicules)
 organisation du travail basée sur le concept des
équipes semi-autonomes
 nouveau rôle du répartiteur.

35. Un exemple d’analyse de processus
35
4 - Le redesign
À partir d'un nouveau concept, l'équipe
propose 12 transformations majeures sur trois
axes :
 le client
 les employés
 les opérations
Gains prévus : 4.000.000 $ sur trois ans

36. Définition d’un Workflow
Conduite de projet 36

37. Définition d’un Workflow
• Le WORKFLOW décrit
 Les tâches à accomplir
 Les acteur d’un processus
 Le circuit et modes de validation
 Les délais
• Le Workflow fournit à chacun des acteurs les
informations nécessaires pour la réalisation de sa
tâche !
37

38. A quoi ça sert ?
• Exemples de Workflow
 un système de rédaction coopérative pour mettre
sous Intranet la documentation professionnelle de
l'entreprise
• Les contributions, validations, approbations etc. parcourent
un workflow qui automatise l'adressage et permet le
contrôle des délais
 un workflow pour la signature des conventions de
partenariat
• actuellement, ces conventions suivent des parcours
compliqués et les délais de signature sont aléatoires
38

39. A quoi ça sert ?
• Exemples de Workflow
 pour la préparation du budget informatique d'une
grande entreprise,
 un workflow permet de rassembler les descriptions de
projets, synthétiser les demandes, préparer les arbitrages.
Il implique les directions, le contrôle de gestion et la
mission système d'information
 Pour la gestion d’un service d'assistance téléphonique
à la force de vente
39

40. Les outils de modélisation
• Le moteur de Workflow
 Dispositif logiciel permettant d’exécuter une ou
plusieurs définitions de Workflow
 Par abus de langage on peut appeler ce dispositif
logiciel « WORKFLOW »
40

41. Les outils de modélisation : MERISE et UML
Conduite de projet 41

42. Les méthodes et diagrammes associés
• Merise
 Sépare les traitements des données
 MCC (Modèle Conceptuel de Communication)
• Méthodes associées à UML
 Unified Modeling Langage
 langage graphique basé sur des concepts OBJETS 
Diagramme de Cas d’Utilisation
42

43. MERISE - MEthode pour Rassembler les Idées Sans Effort
Conduite de projet 43

44. La méthode MERISE (Principes)
• Création : en 1978-79 par Peter Chen et Hubert
Tardieu à Aix en Provence
• Signifie : MEthode pour Rassembler les Idées
Sans Effort ou encore vient du merisier qui est un
porte-greffe !
• But : Conception de Système d'Information (SI)
par la modélisation Pour projets de toutes tailles
44

45. La méthode MERISE (Principes)
La méthode MERISE s'appuie sur 3 points :
• Le cycle de vie (très variable selon les projets)
 Gestation et Conception
 Réalisation et Exploitation
 Maintenance (évolution, adaptation, mort)
• Le cycle de spécification (ou d'abstraction) du
système d'information (SI)
 Domaine des données : la mémorisation de l'information
 Domaine des traitements : les processus de traitement de
l'information
• Le cycle de décision
45

46. 46
Exemple d’un MCC
Réalisation d’un Modèle Conceptuel
de Communication (MCC)

47. Exemple de MCC
Une entreprise commerciale est constituée de trois services
principaux : ventes, comptabilité et magasin.
Pour chaque commande passée, le bon est transmis du service
vente au service comptabilité qui envoie la facture au client (qui
lui, renverra le règlement).
Le service ventes enverra un bon de sortie au magasin pour le
déstockage. Ce dernier envoie le bon de livraison et
la commande au client.
En ce qui concerne les stocks, c'est le magasin qui décide seul du
réapprovisionnement auprès du fournisseur.

48. Exemple de MCC
On dénombre cinq acteurs : Client, Service ventes,
Service comptabilité, Magasin et Fournisseur.
On dénombre ensuite sept flux :
(1) et (2) Bon de commande : (du client au service ventes et du
service ventes au service comptabilité).
(3) Facture : du service comptabilité au client.
(4) Règlement : du client au service comptabilité.
(5) Bon de sortie : du service ventes au magasin.
(6) Bon de livraison+commande : du magasin vers le client.
(7) Bon de commande fournisseur pour éventuel
réapprovisionnement: du magasin vers le fournisseur.

49. Exemple de MCC
Service
Ventes
Service
Compta
Client
Fournisseur
Magasin
1
2
3
4
5
6
7
Référentiel
Décision

50. MERISE MCC - Modèle conceptuel de la communication
Conduite de projet 50

51. Merise : le niveau conceptuel
• Le Modèle Conceptuel de Communication (MCC)
définit les flux et les domaines
 Inventaire des informations et données
 Délimitation du système étudié
• Le modèle Conceptuel de Traitement (MCT) décrit
les règles et les contraintes générales du SI.
• Le Modèle Conceptuel de Données (MCD) décrit
l'organisation des données
Cohérence du MCD / MCC et au MCT
Validation par l'utilisateur
51

52. Modèle conceptuel de communication (MCC)
• N'existait pas dans les premières versions de MERISE
• A été introduit en rapport avec les Use Case d'UML
• Approche systémique : une entreprise est un
système. L'entreprise échange avec l'extérieur, avec
d'autres systèmes. Tout système interne ou externe est
appelé INTERVENANT.
• Tout système se décompose en sous systèmes
fonctionnels ou INTERVENANTs.
52

53. Modèle conceptuel de communication (MCC)
53
Le type DOMAINE est représenté par un grand ovale (ou patatoïde) regroupant
le cas échéant des sous domaines (plus petits ovales). Dans chaque ovale on
indique le nom du domaine.
Le type MESSAGE est représenté par une flèche entre deux domaines et/ou
intervenants avec le nom du message écrit au dessus de la flèche

54. Modèle conceptuel de communication (MCC)
54
Un DOMAINE est un système ou sous-système qui a une mémoire et un SI. Un
domaine est fonctionnel, il joue un rôle. Un domaine peut se décomposer en sous-
domaines.
Exemple : une entreprise (qui est un domaine) se compose des domaines Vendre,
Produire, Gérer le personnel ; ses partenaires sont Client, Etat, …

55. Modèle conceptuel de communication (MCC)
• Pour une entreprise de livraison on pourra distinguer
les Intervenants : LIVRER, FACTURER, ENCAISSER
• Un PARTENAIRE est un intervenant extérieur à
l'entreprise.
• Exemples de partenaires FONCTIONNELs: CLIENT qui
paye, FOURNISSEUR qui approvisionne, …
• Un partenaire est PHYSIQUE s'il est vu
fonctionnellement sous plusieurs facettes.
• Exemple : EDF est à la fois un fournisseur et un client
pour l'entreprise qui construit des transformateurs
électriques.
55

56. Modèle conceptuel de communication (MCC)
• Définition
 Un MCC détermine, par affinage successifs des
activités, la composition du domaine d'étude sans en
décrire le comportement.
• Le MCC se construit par raffinement successif
56

57. Modèle conceptuel de communication (MCC)
• Définition :
 Le MCC détermine le domaine d'étude et ses
échanges avec l'environnement.
• Concepts associés
 Domaine d'étude
 Acteurs externes
 Domaines connexes
 Message
57

58. MCC : Les concepts associés
• Domaine d'étude
– Sous ensemble cohérent de l'entreprise ou de l'organisme, bien
délimité et formant le contenu du sujet à étudier
• Activité
– Ensemble de traitements homogènes qui transforment ou manipulent
des données
• Message
– Représentation d'un échange d'informations entre deux composants
du système ou entre un composant du système et un système
extérieur
• Acteur externe
– Source ou destination de données située en dehors du système étudié

59. Gammes opératoires
• Objectifs
– Partitionner le domaine étudié en activités
– Point de passage obligé pour modéliser les traitements
– Maitriser la progression vers le détail du système
• Niveau de détail
– On s'arrête quand l'activité correspond à une opération.
• Démarche
– Identifier les flux de données entrant et sortant du domaine
– Identifier les activités
– Raffiner par conservation ou décomposition

60. Définition de l'organisation
• La première étape de ce modèle est d'arriver à isoler
le système en le délimitant. Il s'agit donc de définir le
système et les éléments externes avec lesquels il
échange des flux d'information. Ces éléments
extérieurs sont appelés acteurs externes (ou
partenaires).

61. Définition de l'organisation
• La seconde étape consiste à découper l'organisation
en entités appelées acteurs internes (ou domaines).
Lorsque les domaines d'une organisation sont trop
importants, ils peuvent être décomposés eux-mêmes
en sous-domaines.

62. Diagramme de contexte
• Le diagramme de contexte a pour but de représenter les flux
d'informations entre l'organisation et les acteurs externes
selon une représentation standard dans laquelle chaque objet
porte un nom :
• l'organisation est représentée par un rectangle
• les acteurs externes sont représentés par des ellipses en
pointillés
• les flux d'information sont représentés par des flèches dont
l'orientation désigne le sens du flux d'information

63. Diagramme conceptuel de flux
• Ce diagramme (appelé aussi modèle conceptuel de la
communication) permet de compléter le diagramme de
contexte en décomposant l'organisation en une série
d'acteurs internes. Dans ce diagramme la représentation
standard est la suivante :
• Les acteurs internes sont représentés par des ellipses
• les messages internes sont représentés par des flèches

64. MERISE MCC – Exemple de Modèle conceptuel de la communication
Conduite de projet 64

65. Exemple de MCC - Niveau 0
Assurance
Assuré
Déclaration de sinistre
Niveau prise en charge
Règlement sinistre
Expert
Garage Agréé
Facture

66. Exemple de MCC - Niveau 1
Sinistre
Auto
Compta
Assuré
Garage Agréé
Expert
Déclaration de sinistre
Niveau prise en
charge
Facture
Ordre de
paiement
Paiement

67. 67
Travail en sous-groupe sur la réalisation d’un MCC
Réalisation d’un Modèle Conceptuel
de Communication (MCC)

68. Exercice Merise MCC
Voici la description du fonctionnement d'une société de services :
Modélisation du système de gestion des affaires d'une société de service.
Le Service Commercial est chargé d'examiner les études de demande client (cahier des
charges). Si ceux-ci correspondent à l'activité de la société, le dossier est transmis à la
Direction Technique qui élabore un devis estimatif. Celui-ci est complété au Service
Commercial, édité et envoyé au client pour accord.
Si le devis commercial est accepté par le client, le Service Commercial adresse une
demande d'étude technique au Service Technique.
Le Directeur Technique élabore des devis techniques qui correspondent à un
découpage en lots du devis technique.
Chaque devis est transmis à un Chef de Projet. Celui-ci procède à un nouveau
découpage technique du devis et établit le planning de réalisation en affectant chacun
des postes du devis technique à un Analyste Programmeur.

69. Exercice Merise MCC
Les Analystes Programmeurs établissent chaque jour un compte rendu d'activité. Chaque
semaine, le Chef de Projet édite un rapport d'avancement et informe la Direction
Technique de la situation des travaux en cours.
Lorsqu'un poste du devis technique est réalisé, le chef de Projet transmet les programmes
au client qui établit un procès verbal de réception. La recette est signalée au Service
Comptable pour facturation.
Chaque mois, une proposition de facture est établie par le Service Comptable et transmise
à la Direction Technique pour être validée. Cette proposition correspond à l'ensemble des
lignes du devis commercial non facturées.
Les factures sont ensuite éditées et envoyées au client par le Service Comptable.
Etablir le M.C.C. correspondant à l'organisation de cette société, en mettant en scène les
acteurs suivants, et en prenant la société comme référentiel :
Le Client.
Le Service Commercial.
La Direction Technique.
Le Chef de Projet.
L'Analyste Programmeur.
Le Service Comptable.

70. Analyse de Process et Workflow 70

71. L’analyse logicielle avec UML (Unified Modeling Langage)
Conduite de projet 71

72. L’analyse logicielle avec UML
Les différents types de diagrammes
Tout comme la construction
d’une maison nécessite des
plans à différents niveaux
(vision extérieure, plan des
différents étages, plans
techniques…), la réalisation
d’une application informatique
ou d’un ensemble d’applications
est basée sur plusieurs
diagrammes.

73. L’analyse logicielle avec UML
Les différents types de diagrammes
Le langage UML est constitué de diagrammes. À ce jour, il
existe 13 diagrammes « officiels ». Ces diagrammes sont tous
réalisés à partir du besoin des utilisateurs et peuvent être
regroupés selon les deux aspects suivants :

74. L’analyse logicielle avec UML
Les différents types de diagrammes
Les aspects fonctionnels : Qui utilisera le logiciel et pour quoi
faire ? Comment les actions devront-elles se dérouler ? Quelles
informations seront utilisées pour cela ?
Les aspects liés à l’architecture : Quels seront les différents
composants logiciels à utiliser (base de données, librairies,
interfaces, etc.) ? Sur quel matériel chacun des composants
sera installé ?
UML modélise donc le système logiciel suivant ces deux modes
de représentation.

75. UML = Unified Modeling Langage
• Nous allons donc dans un premier temps décrire ces différents
aspects d’un logiciel grâce au schéma 4+1 vues et parcourir
brièvement les différents diagrammes qui les composent

76. La vue (4 + 1)
• Vue des besoin utilisateurs
– Cette vue (dont le nom exact est "vue des cas
d'utilisation"), guide toutes les autres
• Vue logique
– Cette vue de haut niveau se concentre sur
l’abstraction et l’encapsulation, elle modélise les
éléments et mécanismes principaux du système
• Vue des processus
– Cette vue est très importante dans les
environnements multitâches

77. La vue (4 + 1)
• Vue des composants
– Cette vue de bas niveau (aussi appelée "vue
de réalisation"), Identifie les modules qui
réalisent (physiquement) les classes de la vue
logique
• Vue de déploiement
– Cette vue très importante dans les
environnements distribués, décrit les
ressources matérielles et la répartition du
logiciel dans ces ressources

78. Vue des cas d’utilisation
• Cette vue guide toutes les autres
– A l'aide de scénarios et de cas d’utilisation,
cette vue conduit à la définition d'un
modèle d'architecture pertinent et cohérent
– Elle définit les besoins des clients du
système et centre la définition de
l'architecture du système sur la satisfaction
(la réalisation) de ces besoins
– Cette vue est la "colle" qui unifie les quatre
autres vues de l'architecture

79. Diagrammes
Dynamiques
 diagramme de cas utilisation
 diagramme de séquences
 diagramme de collaborations
 diagramme d‘états-transitions
 diagramme d‘activité
Statiques
 diagramme de classes
 diagramme d‘ objets
 diagramme de composants
 diagramme de déploiement

80. 3 axes de modélisation
Fonctionnel
Statique
Dynamique
- Diagramme de Use Cases
(diagramme d’activité)
(diagramme de séquence)
- Diagramme de Classe
(diagramme d’objet)
- Diagramme de composants
(diagramme de déploiement)
- Diagramme d’état
(diagramme d’activité)
(diagramme de séquence)
- Diagramme de collaboration

81. L’analyse logicielle avec UML (Zoom sur le Use Cases)
Conduite de projet 81

82. Cas d’utilisation
• Ce diagramme décrit les situations auxquelles
le système doit répondre.
• Il permet d’établir les fonctionnalités
nécessaires au bon fonctionnement d’un site
internet, quels sont les différents acteurs et
quelles relations existent entre eux
– On se place du point de vue de l'utilisateur.

83. Diagramme de cas d’utilisation
• Il contient
– des acteurs : ce sont des personnes ou systèmes extérieurs
à l'application, et qui interagissent avec elle.
– des cas d'utilisation : représentent une fonctionnalité (un
objectif à atteindre) du système à construire. Ils sont en
relation avec des acteurs et d'autres cas d'utilisation
– des relations : elle sont généralement orientées
– le système : représente l'application et les cas d'utilisation
– Les packages : correspondent à des regroupements logiques

84. Diagramme de cas d’utilisation

85. Diagramme de cas d’utilisation
Acteur : se représente sous la forme d’un petit
personnage ou sous la forme de classe avec le mot clé
<<acteur>>
Note : se représente sous la forme de « papier plié »
précisant certaines contraintes
Cas d’utilisation : se représente sous la forme d’ellipse.
Les cas d’utilisation peuvent être contenus dans un
rectangle qui représente les limites du système
Association : représente la relation entre un acteur et un
cas d’utilisation, elle se schématise par un trait.
<<Acteur>>
Nom de
l’acteur

86. • Les relations entre cas d’utilisation
– Relation de généralisation
• Le cas d’utilisation enfant est une spécialisation du
cas d’utilisation parent qui peut être abstrait.
Cas d’utilisation
Enfant
Cas d’utilisation
Parent
Cas d’utilisation

87. Cas d’utilisation
• Les relations entre cas d’utilisation
– Relation d’inclusion
• Cette relation permet de décomposer les
comportements et de définir des comportements
partageables entre plusieurs cas d’utilisation.
• Une instance du cas d ’utilisation source comprend le
comportement décrit dans le cas d’utilisation
destination.
Cas d’utilisation Destination
Cas d’utilisation Source
<<inclus>>

88. Cas d’utilisation
• Les relations entre cas d’utilisation
– Relation d’extension
• Le cas d’utilisation source ajoute son comportement
au cas d’utilisation destination.
• Elle permet de modéliser des variantes de
comportement d’un cas d’utilisation.
<<étend>>
Cas d’utilisation Destination
Cas d’utilisation Source

89. Cas d’utilisation
• Exemple des différentes relations entre cas
d’utilisation
Virement
Point d’extension :
vérification
supplémentaire après
identification
Client local
Client distant
Virement
par
internet
Identification
<<inclus>>
Vérification
solde compte
<<étend>>
si Montant > 100 €

90. L’analyse logicielle avec UML (Le diagramme de séquence)
Conduite de projet 90

91. Diagramme de séquence
• Le Diagramme de séquence présente un
écoulement dans le temps. Il séquence les
différents messages.
• Ce diagramme montre les messages avec
valeur et sans valeur qui sont échangés entre
les différents acteurs.
• La notion de temps est importante elle
permet de temporiser et d’ordonner les
messages.

92. Diagramme de séquence
Système
Porteur de CB
SA Visa/Mastercard
Introduction carte
Demande de code secret
Code (valeur)
Demande autorisation
Autorisation (solde)
Demande montant retrait
Retrait (valeur)
Demande ticket
OK
éjection carte
Récupérer carte
Éjection billets + ticket
Récupération billets + ticket
Axedutemps
Vérification carte
Vérification code Voir A2 et B4
code erroné
Contrôle montant
Voir A6 ticket refusé

93. L’analyse logicielle avec UML (Les diagrammes)
Conduite de projet 93

94. Les diagrammes UML
• Voici quelques exemples de diagramme qui peuvent être utilisés
dans une démarche d’analyse et de conception d’un logiciel. Ne
vous inquiétiez pas du nombre de diagrammes ci-dessous. Il s’agit
ici simplement de vous familiariser à ces diagrammes.
• L’objectif est d’avancer pas à pas dans l’analyse des besoins initiaux
des utilisateurs, afin de travailler plus particulièrement les 4
diagrammes suivants :
1. le diagramme de contexte. Ce diagramme n’est pas officiellement
désigné comme diagramme UML. Il ne fait donc pas partie des 13
diagrammes « officiels », mais il est utile pour la définition des
acteurs, avant de commencer à s’intéresser à d’autres aspects,
tels que les packages et les cas d’utilisation.
2. le diagramme de package
3. le diagramme de cas d’utilisation
4. le diagramme d’activité.

95. Les besoins des utilisateurs (1)
• Cette partie représente le cœur de l’analyse. Il est
composé de cas d’utilisation (que nous verrons
plus tard). On y décrit le contexte, les acteurs ou
utilisateurs du projet logiciel, les fonctionnalités
du logiciel mais aussi les interactions entre ces
acteurs et ces fonctionnalités. C’est d’ailleurs
aussi le cœur de notre cours.
• Le besoin des utilisateurs peut être décrit à
l’aide de deux diagrammes.

96. Les besoins des utilisateurs (1)
• Le diagramme de packages permet de décomposer le système en catégories ou
parties plus facilement observables, appelés « packages ». Cela permet également
d’indiquer les acteurs qui interviennent dans chacun des packages.

97. Les besoins des utilisateurs (1)
• Dans l’exemple précédent, nous voyons que le logiciel
que nous concevons peut être divisé en trois parties
(ou packages) observables séparément :
• La gestion des commandes client
• La gestion des stocks
• La gestion des achats
•
• La boîte qui entoure les packages (la boîte bleue)
correspond au système (c’est-à-dire le logiciel) qui est
analysé.

98. Les besoins des utilisateurs (1)
• Le diagramme de cas d’utilisation représente les fonctionnalités (ou dit
cas d’utilisation) nécessaires aux utilisateurs. On peut faire un diagramme
de cas d’utilisation pour le logiciel entier ou pour chaque package.
Étant donné que le diagramme de cas d’utilisation détaille le contenu d’un
package, ici la boîte bleue correspond au package qui est détaillé.

99. Vue logique (2)
• La vue logique a pour but d’identifier les
éléments du domaine, les relations et
interactions entre ces éléments. Cette vue
organise les éléments du domaine en «
catégories ». Deux diagrammes peuvent être
utilisés pour cette vue.

100. Vue logique (2)
• Le diagramme de classes
• Dans la phase d’analyse, ce diagramme représente les entités (des informations)
manipulées par les utilisateurs. Dans la phase de conception, il représente la
structure objet d’un développement orienté objet.

101. Vue logique (2)
• Le diagramme d’objets sert à illustrer les classes complexes en utilisant
des exemples d’instances. Une instance est un exemple concret de
contenu d’une classe. En illustrant une partie des classes avec des
exemples (grâce à un diagramme d’objets), on arrive à voir un peu plus
clairement les liens nécessaires

102. Vue des processus (3)
• La vue des processus démontre :
• la décomposition du système en processus et
actions ;
• les interactions entre les processus ;
• la synchronisation et la communication des
activités parallèles.
• La vue des processus s’appuie sur plusieurs
diagrammes.

103. Vue des processus (3)
• Le diagramme de séquence permet de décrire
les différents scénarios d’utilisation du
système.

104. Vue des processus (3)
• Le diagramme d’activité représente le déroulement des actions,
sans utiliser les objets. En phase d’analyse, il est utilisé pour
consolider les spécifications d’un cas d’utilisation.

105. Vue des processus (3)
• Le diagramme de collaboration (appelé également diagramme de
communication) permet de mettre en évidence les échanges de messages
entre objets. Cela nous aide à voir clair dans les actions qui sont
nécessaires pour produire ces échanges de messages. Et donc de
compléter, si besoin, les diagrammes de séquence et de classes.

106. Vue des processus (3)
• Le diagramme d’état-transition permet de
décrire le cycle de vie des objets d’une classe

107. Vue des processus (3)
• Le diagramme global
d’interaction permet de
donner une vue
d’ensemble des
interactions du système.
Il est réalisé avec le
même graphisme que le
diagramme d’activité.
Chaque élément du
diagramme peut ensuite
être détaillé à l’aide d’un
diagramme de séquence
ou d’un diagramme
d’activité.

108. Vue des processus (3)
• Le diagramme de temps est destiné à l’analyse et la conception de
systèmes ayant des contraintes temps-réel. Il s’agit là de décrire les
interactions entre objets avec des contraintes temporelles fortes.

109. L’aspect lié à l’architecture du logiciel
• Pour rappel, cette partie du schéma 4+1 vue
permet de définir les composantes à utiliser
(exécutables, interfaces, base de données,
librairies de fonctions, etc.) et les matériels sur
lesquels les composants seront déployés.

110. Vue des composants (4)
• La vue des composants (vue de réalisation)
met en évidence les différentes parties qui
composeront le futur système (fichiers
sources, bibliothèques, bases de données,
exécutables, etc.).
• Cette vue comprend deux diagrammes :

111. Vue des composants (4)
• Le diagramme de structure composite décrit
un objet complexe lors de son exécution.

112. Vue des composants (4)
• Le diagramme de composants décrit tous les
composants utiles à l’exécution du système
(applications, librairies, instances de base de
données, exécutables, etc.).

113. Vue de déploiement (5)
• La vue de déploiement décrit les ressources
matérielles et la répartition des parties du
logiciel sur ces éléments. Il contient un
diagramme :
• Le diagramme de déploiement correspond à
la description de l’environnement d’exécution
du système (matériel, réseau…) et de la façon
dont les composants y sont installés.

114. Vue de déploiement (5)

115. En synthèse
• UML est constitué de 13 diagrammes qui
représentent chacun un concept du système ou
logiciel.
• Un logiciel peut être vu en considérant les
aspects fonctionnels et les aspects d’architecture
du logiciel. Ces deux aspects sont composés de 4
vues du logiciel à développer, organisés autour
des besoins des utilisateurs. C’est le 4+1 vues.
• Chacune des 4+1 vues est constituée de
diagrammes.

116. Merci de votre attention
116