ALI SAADI

QUELLE MÉTHODE ADOPTER POUR MODELISER

LES PROCESSUS MÉTIER DE L'ADMINISTRATION ?

Mémoire présenté
à la Faculté des études supérieures de l'Université Laval
dans le cadre du programme de maîtrise en informatique
pour l'obtention du grade de maître es sciences (M.Se.)

DÉPARTEMENT D'INFORMATIQUE ET GÉNIE LOGICIEL

FACULTÉ DES SCIENCES ET DE GÉNIE
UNIVERSITÉ LAVAL
QUÉBEC

2006

'Ali Saadi, 2006

 RESUME

Face à l'évolution incessante des systèmes d'informations et de leur complexité

croissante, l'enjeu, sans nul doute le plus important dans les années à venir, est de
construire le « parfait » système d'informations ou du moins maintenir un système
d'informations cohérent, compréhensible, non impossible à gérer et au sein duquel les
labyrinthes ne conduisent pas à des impasses ou nulle part. Longtemps cantonnées
dans une vision purement informatique, les organisations ne peuvent se passer d'une
approche qui englobe aussi bien le monde des métiers que celui de l'informatique.
Adopter une vision par processus métier, au lieu de celle par projet, par application ou
par besoin isolé, contribuera certainement à instaurer un langage commun à travers
lequel les responsables métiers et les techniciens de l'information communiquent et font
correspondre leurs perceptions globales de la réalité opérationnelle de l'entreprise et
ses conséquences sur les visions organisationnelle et informationnelle dont ils ont
respectivement la charge. Cependant, la prolifération des méthodes et des outils de
modélisation et leur complexité ne facilitent guère cette unification des vues.
Dans ce travail, nous nous sommes intéressés aux processus métier et à leur
modélisation. Le but de cette étude est de présenter un échantillon des méthodes et des
outils disponibles sur le marché et traitant de la modélisation des processus métier, et de
s'en inspirer afin de proposer les principes d'une nouvelle méthode qui soit simple, facile
à utiliser et surtout applicable dans son intégralité. Cet objectif de simplicité, de facilité et
d'intégralité émane principalement du constat que les méthodes actuelles sont trop
complexes pour l'usager, soit par le langage utilisé, souvent sophistiqué ou trop
technique, soit par leur recherche d'universalité (être applicables à tous les cas et à
toutes les organisations). Ensuite, nous avons appliqué la méthode, proposée, à un cas
réel afin de nous permettre de détecter les points forts, les points faibles ainsi que la
perception des acteurs qui ont participé à l'application de la méthode. Un bilan sur les
apports de la méthode proposée ainsi que ses limites et ses perspectives est fourni en
conclusion.
 REMERCIEMENTS

Réaliser ce mémoire en l'espace de trois années, tout en occupant une fonction à plein
temps, a été pour moi un défi majeur. Ce défi n'aurait certainement pas abouti sans le
support de plusieurs personnes que j'aimerais remercier ici.

Premièrement, je remercie mon directeur de recherche M. Bernard Moulin pour son

soutien, sa disponibilité et ses précieux conseils fournis avec générosité tout au long de
la réalisation de ce projet. Il a toujours su comment me diriger vers la bonne direction,
tout en m'accordant toute sa confiance.

Je désire, également, remercier les professeurs Nadir Belkhiter et Luc Lamontagne pour
avoir accepté d'évaluer ce mémoire et d'être les membres du jury malgré leurs
nombreuses charges.

Je voudrais aussi remercier ma famille et mes amis qui ont été, sans le savoir, une
source de motivation pour moi. Je tiens particulièrement à remercier mon frère, mon
épouse et mes enfants pour leur soutien inconditionnel malgré qu'ils ont du subir mes
nombreuses heures de travail sur ce mémoire le soir et les fins de semaines.

Je ne pourrai passer sous silence l'opportunité que m'a procurée la Direction des
systèmes d'information du Ministère de l'Éducation, du Loisir et du Sport de faire cette
maîtrise. Ici je voudrais remercier, particulièrement, mon directeur M. Louis-Philippe
Pelletier et ma chef de service Mme Hélène Doyon pour les facilités qu'ils m'ont
accordées pour réaliser ce rêve et pour leur soutien continu. Je remercie également mes
amis Renée Labrecque et Yves Sicard pour leurs encouragements durant toute cette
période et qui ont constitué l'une de mes meilleures sources d'inspiration.

Je tiens aussi à remercier, sans exception, tout le personnel du Ministère qui m'ont
permis de réaliser le cas d'étude de ce mémoire et sans lesquels je n'aurais pas pu
terminer ce travail. J'espère qu'ils trouvent, ici, l'expression de mon éternelle
reconnaissance.
Je dédie ce mémoire à mon père qui m'a appris le sens de la persévérance.
 TABLES DES MATIÈRES

RÉSUMÉ I
REMERCIEMENTS Il
TABLES DES MATIÈRES IV
LISTE DES FIGURES VII
LISTE DES TABLEAUX VIII
CHAPITRE 1 : INTRODUCTION 1
1.1. Domaine de l'étude 1
1.2. La problématique 3
1.3. Objectifs du mémoire 6
1.4. Démarche 6
1.5. Structure du mémoire 7
CHAPITRE 2 : MODÉLISATION DES PROCESSUS MÉTIER 8
2.1. Introduction 8
2.2. Notions de processus métier et de modèles 9
2.3. Rôle des modèles 11
2.4. Modélisation des processus métier 13
2.5. Comprendre le métier 15
2.6. Améliorer le métier 16
2.7. Concevoir de nouveaux métiers 17
2.8. Sous-traiter les métiers non rentables 17
2.9. Niveaux de modélisation 18
2.10. Techniques de méta-modélisation 20
2.11. Apports de la méta-modèlisation 25
2.12. CONCLUSION 26
CHAPITRE 3 : MÉTHODES ET OUTILS 28
3.1. Introduction 28
3.2. Méthodes de modélisation 30
3.3. Cadre de comparaison 33
3.4. Utilisation du cadre de comparaison pour l'évaluation 38
3.4.1. La méthode MERISE 39
3.4.2. La méthode OMT 42
3.4.3. UML 44
3.4.4. La méthode SADT 46
3.4.5. La méthode OSSAD 48
3.4.6. UP (Unified Process) 50
3.4.7. Processus 2TUP (2 Tracks Unified Process) 55
3.4.8. Méthode Gestion des ParcourS (GPS) 62
3.4.8.1. Parcours général de développement 63
3.4.8.2. Activité : Définir les éléments architecturaux de la solution 64
3.4.8.3. Activité : Analyser la solution informatique 65
3.4.8.4. Activité : Construire la solution informatique 66
3.4.8.5. Activité : Implanter et déployer la solution informatique 68
3.5. Outils de modélisation 72
3.6. Évaluation des outils testés 75
3.6.1. ADONIS 75
3.6.2. Allfusion Process Modeler 77
3.6.3. ARIS Tool Set 78
3.6.4. iGrafx PROCESS 80
3.6.5. MEGA Process 82
3.6.6. OSS@D Process Design 83
iv
3.6.7. QUALIGRAM Manager 85
3.7. Conclusion 86
CHAPITRE 4 : CHOIX DE LA MÉTHODE 89
4.1. Introduction 89
4.2. Caractéristiques des méthodes utilisées au sein de l'administration 90
4.3. Description de la méthode proposée 92
4.4. La phase d'initialisation de l'étude 93
4.4.1 Planifier l'initialisation de l'étude 94
4.4.2 Clarifier la demande 95
4.4.3 Préparer et présenter le rapport d'initialisation 95
4.5. La phase d'étude préliminaire 97
4.5.1 Planifier l'étude préliminaire 98
4.5.2 Recueillir l'information préliminaire sur le PM objet 98
4.5.3 Identifier les domaines 100
4.5.4 Identifier les processus métier 102
4.5.5 Définir la frontière du processus métier objet 104
4.5.6 Modéliser le contexte du PM objet 106
4.5.7 Préparer et présenter le rapport de l'étude préliminaire 110
4.6. La phase du diagnostic de l'existant 113
4.6.1 Planifier le diagnostic de l'existant 114
4.6.1.1 Former l'équipe 114
4.6.1.2 Choisir les outils de travail 114
4.6.1.3 Dresser un échéancier 116
4.6.2 Analyser l'environnement 117
4.6.3 Collecter l'information sur le PM objet 118
4.6.4 Collecter l'information sur les composantes 119
4.6.5 Collecter l'information sur les performances 121
4.6.6 Collecter l'information sur les problèmes 124
4.6.7 Modéliser le PM objet 126
4.6.8 Construire le modèle global du PM objet 129
4.6.9 Construire les modèles des sous-processus du PM objet 131
4.6.10 Établir le diagnostic 133
4.6.11 Préparer et présenter le rapport du diagnostic 135
4.7. La phase d'analyse 138
4.7.1 Planifier l'analyse 139
4.7.1.1 Former l'équipe 139
4.7.1.2 Dresser un échéancier 140
4.7.2 Proposer des solutions 140
4.7.3 Élaborer les nouveaux modèles du PM objet 143
4.7.4 Préparer et présenter le rapport d'analyse 144
4.8. Conclusion 147
CHAPITRE 5 : ÉTUDE DE CAS 149
5.1. Introduction 149
5.2. Contexte du cas étudié 150
5.3. La phase d'initialisation de l'étude 152
5.3.1 Planification de l'initialisation de l'étude 153
5.3.2 Clarification de la demande 154
5.4. La phase d'étude préliminaire 155
5.4.1 Planification de l'étude préliminaire 156
5.4.2 Recueil de l'information préliminaire sur le PM objet 157
5.4.2.1 Mission de la DAS 157
5.4.2.2 Processus métier objet de l'étude 158
5.4.2.3 Problèmes perçus par les personnes consultées 163
5.4.3 Identification des domaines 163
5.4.4 Identification des processus métier 164
5.4.5 Définition de la frontière du processus métier objet 167
5.4.6 Modèle de contexte du PM objet 169
5.5. La phase du diagnostic de l'existant 174
5.5.1 Planification du diagnostic de l'existant 174
5.5.1.1 Formation de l'équipe 174
5.5.1.2 Échéancier des travaux 175
5.5.1.3 Choix des outils de travail 175
5.5.2 Analyse de l'environnement du PM objet 176
5.5.3 Information sur le PM objet 178
5.5.4 Collecte de l'information sur les composantes 178
5.5.5 Collecte de l'information sur les performances 179
5.5.6 Collecte de l'information sur les problèmes 181
5.5.7 Modélisation du PM objet 184
5.5.7.1 Construction du modèle global du PM objet 184
5.5.7.2 Construction des modèles des sous-processus du PM objet 187
5.5.7.3 Modèle du ss-pm 1- Élaborer formulaire et lettre d'information 187
5.5.7.4 Modèle du ss-pm 2- Saisir formulaire et lettre d'information 188
5.5.7.5 Modèle du ss-pm 3-Valider formulaire et lettre d'information 189
5.5.7.6 Modèle du ss-pm 4- Envoyer formulaire et lettre d'information 189
5.5.7.7 Modèle du ss-pm 5- Réceptionner projet 190
5.5.7.8 Modèle du ss-pm 6- analyser projet.... 192
5.5.7.9 Modèle du ss-pm 7- Élaborer synthèse des bilans 194
5.5.7.10 Modèle du ss-pm 8- Élaborer statistiques 195
5.5.8 Pose du diagnostic 196
5.6. La phase d'analyse 200
5.6.1 Planification de l'analyse 200
5.6.1.1 Formation de l'équipe 200
5.6.1.2 Échéancier des travaux 201
5.6.2 Proposition des solutions 201
5.6.3 Élaboration des nouveaux modèles du PM objet 208
5.6.3.1 Objectifs du nouveau PM objet 209
5.6.3.2 Objectifs du nouveau PM cible (partie à automatiser) 209
5.6.3.3 Bénéfices 210
5.6.3.4 Modèle global du nouveau PM objet 211
5.6.3.5 Modèles des ss-pm du nouveau PM objet 214
5.6.3.6 Modèle du ss-pm 1- Élaborer lettre d'information 214
5.6.3.7 Modèle du ss-pm 2- Saisir lettre d'information 215
5.6.3.8 Modèle du ss-pm 3- Valider lettre d'information 216
5.6.3.9 Modèle du ss-pm 4- Envoyer lettre d'information 216
5.6.3.10 Modèle du ss-pm 5- Gérer les demandes 217
5.6.3.11 Modèle du ss-pm 6- Gérer les bilans 222
5.6.3.12 Modèle du ss-pm 7- Exploiter la BD 224
5.7. Diagramme des cas d'utilisation (CU) 225
5.8 Conclusion 228
CHAPITRE 6 : CONCLUSION GÉNÉRALE 231
6.1 Introduction 231
6.2 Tableau comparatif des méthodes 234
6.3 Bilan et apports de la méthode 240
6.4 Limites et perspectives 243
BIBLIOGRAPHIE 245
ANNEXES 249

vi
 LISTE DES FIGURES

Figure 1 Architecture à quatre niveaux [3] 20

Figure 2 L'architecture quatre couches [3] 21
Figure 3 Les deux bus d'interopérabilité de l'OMG [3] 22
Figure 4 Le système du point de vue de l'utilisateur [15] 24
Figure 5 Le système du point de vue du développeur [15] 24
Figure 6 Différents points de vue sur les processus [1] 25
Figure 7 Processus UP [48] 52
Figure 8 Processus de développement en Y (adaptée de [49]) 55
Figure 9 Démarche de capture initiale des besoins ([49]) 58
Figure 10 Démarche de capture des besoins fonctionnels ([49]) 59
Figure 11 Démarche de l'étape d'analyse ([49]) 60
Figure 12 Activités du parcours général de développement [50] 63
Figure 13 Tâches de l'activité Définir les éléments architecturaux de la solution [50] 64
Figure 14 Tâches de l'activité Analyser la solution informatique [50] 66
Figure 15 Tâches de l'activité Construire la solution informatique [50] 67
Figure 16 Tâches de l'activité Implanter et déployer la solution informatique [50] 69
Figure 17 Activités et produits de la phase d'initialisation 96
Figure 18 Exemple de diagramme d'organisation d'une UO 101
Figure 19 Diagramme de contexte du processus métier «Gestion des commandes » 110
Figure 20 Activités et produits de l'étude préliminaire 112
Figure 21 Symboles ANSI pour représenter les processus [57] 128
Figure 22 Modèle global du PM objet « Gestion des commandes » 130
Figure 23 Modèle sous-processus « Prendre la commande-client » 131
Figure 24 Modèle sous-processus « Préparer la livraison » 132
Figure 25 Activités et produits de la phase du diagnostic 137
Figure 26 Activités et produits de la phase d'analyse 146
Figure 27 diagramme d'organisation de la DAS 163
Figure 28 Diagramme de contexte du processus métier SoReDAS 173
Figure 29 Modèle global du PM objet SoReDAS 186
Figure 30 Modèle du sous-processus «1- Élaborer formulaire et lettre d'information» 188
Figure 31 Modèle du sous-processus «2- Saisir formulaire et lettre d'information» 188
Figure 32 Modèle du sous-processus «3-Valider formulaire et lettre d'information» 189
Figure 33 Modèle du sous-processus «4- Envoyer formulaire et lettre d'information» 190
Figure 34 Modèle du sous-processus «5- Réceptionner projet» 191
Figure 35 Modèle sous-processus «6- analyser projet» 193
Figure 36 Modèle sous-processus «7- Élaborer synthèse des bilans» 194
Figure 37 Modèle sous-processus «8- Élaborer statistiques» 195
Figure 38 Modèle global du nouveau PM objet SoReDAS 213
Figure 39 Modèle du ss-pm « 1- Élaborer lettre d'information » 215
Figure 40 Modèle du ss-pm « 2- Saisir lettre d'information » 215
Figure 41 Modèle du sous-processus «3- Valider lettre d'information» 216
Figure 42 Modèle du sous-processus «4- Envoyer lettre d'information» 217
Figure 43 Modèle du sous-processus «5- Gérer les demandes» 221
Figure 44 Modèle du sous-processus «6- Gérer les bilans» 223
Figure 45 Modèle du sous-processus «7- Exploiter la BD» 225
Figure 46 Diagramme des CU du ss-pm « 5-Gérer les demandes » 227

VII
 LISTE DES TABLEAUX

Tableau 1 Évolution des langages : 31

Tableau 2 Critères de comparaison .....38
Tableau 3 Analyse de la méthode MERISE 42
Tableau 4 Analyse de la méthode OMT 44
Tableau 5 Analyse de la méthode UML 46
Tableau 6 Analyse de la méthode SADT 47
Tableau 7 Analyse de la méthode OSSAD 50
Tableau 8 Analyse de la méthode UP 54
Tableau 9 Analyse du processus 2TUP 62
Tableau 10 Analyse de la méthode GPS 71
Tableau 11 Fonctionnalités testées 75
Tableau 12 Fiche d'identité d'ADONIS 76
Tableau 13 Résultas de l'évaluation d'ADONIS 76
Tableau 14 Fiche d'identité de Allfusion Process Modeler 77
Tableau 15 Résultas de l'évaluation de Allfusion Process Modeler 77
Tableau 16 Fiche d'identité de ARIS Tool Set 78
Tableau 17 Résultas de l'évaluation de ARIS Tool Set 79
Tableau 18 Fiche d'identité de iGrafx PROCESS 80
Tableau 19 Résultas de l'évaluation de iGrafx PROCESS 81
Tableau 20 Fiche d'identité de MEGA Process 82
Tableau 21 Résultas de l'évaluation de MEGA Process 82
Tableau 22 Fiche d'identité de OSS@D Process Design 84
Tableau 23 Résultas de l'évaluation de OSS@D Process Design 84
Tableau 24 Fiche d'identité de QUALIGRAM Manager 85
Tableau 25 Résultas de l'évaluation de QUALIGRAM Manager 86
Tableau 26 Liste des domaines de l'UO « Gestion de la production » 102
Tableau 27 Liste des processus métier du domaine « Commercial » 103
Tableau 28 Les déterminants de la frontière du processus métier objet 105
Tableau 29 Stéréotypes proposés par Rational Rosé [56] 107
Tableau 30 Liste des acteurs du processus métier « Gestion des commandes » 109
Tableau 31 Exemple de table des matières pour le rapport d'étude préliminaire 112
Tableau 32 Les composantes du processus métier objet 121
Tableau 33 Les critères d'efficacité des sorties (outputs) d'un PM 123
Tableau 34 Les critères d'efficience d'un PM 124
Tableau 35 Liste des problèmes et leurs causes probables 125
Tableau 36 Liste des problèmes, leurs causes probables et leurs impacts 134
Tableau 37 Exemple de table des matières pour le rapport du diagnostic 136
Tableau 38 Éléments de solutions 142
Tableau 39 Exemple de table des matières pour le rapport d'analyse 145
Tableau 40 Ressources affectées au projet 153
Tableau 41 Planning des rencontres 153
Tableau 42 Échéancier des travaux 154
Tableau 43 Planning de l'étude préliminaire 156
Tableau 44 Liste des domaines de la DAS 164
Tableau 45 Liste des processus métier du domaine «Définition des politiques et règlements EHDAA»
165

VIII
Tableau 46 Liste des processus métier du domaine «Suivi des déficiences et évaluation des
programmes» 167
Tableau 47 Liste des processus métier du domaine «Gestion du budget» 167
Tableau 48 Les déterminants de la frontière du processus métier objet 169
Tableau 49 Liste des acteurs du processus métier « SoReDAS » 172
Tableau 50 Ressources affectées au projet 174
Tableau 51 Échéancier des travaux 175
Tableau 52 Données confinées 178
Tableau 53 Les composantes du processus métier objet 179
Tableau 54 Les critères d'efficacité des sorties (outputs) d'un PM 180
Tableau 55 Les critères d'efficience d'un PM 181
Tableau 56 Liste des problèmes et leurs causes probables 183
Tableau 57 Liste des problèmes, leurs causes probables et leurs impacts 199
Tableau 58 Ressources affectées au projet 200
Tableau 59 Échéancier des travaux 201
Tableau 60 Éléments de solutions 206
Tableau 61 Solutions retenues 208
Tableau 62 Comparaison des méthodes 238
Tableau 63 Comparaison de la méthode proposée avec les autres méthodes étudiées 240

IX
CHAPITRE 1 : INTRODUCTION

1.1. Domaine de l'étude

Depuis des décennies, les organisations ont dû s'investir d'une façon significative dans
l'utilisation des technologies de l'information pour automatiser les divers processus
intervenant dans le cycle de vie de leurs missions.
Ce besoin d'automatisation a contribué à l'apparition de nombreuses méthodes et outils
de gestion de l'information et par conséquent à la prolifération de modèles et de types
de modèles de systèmes d'information. Des modèles où l'information se trouve
morcelée sur plusieurs systèmes où on ne fait que gérer des vues partiellement
indépendantes et souvent transversales sans une vue d'ensemble.

Après avoir réalisé des prouesses et déchargé de nombreuses personnes de tâches

répétitives, compliquées ou sans grand intérêt pour l'individu, l'informatique a peu à peu
perdu de sa superbe et se retrouve confrontée aux mêmes contraintes économiques et
fonctionnelles que les autres unités de l'entreprise. Tentaculaire, compliquée, peu
flexible, engloutissant des budgets de plus en plus importants, elle est l'objet de
critiques récurrentes, d'insatisfactions chroniques et de déceptions largement exprimées
et partagées.

Ce sentiment s'est trouvé peu à peu renforcé par le jugement exprimé par certains
gestionnaires et utilisateurs vis-à-vis de leur informatique et qu'ils formulent, selon
l'occasion et la conjoncture, par :
• Des services non conformes;
• Des redondances conflictuelles;
• Des échéances non respectées;
• Des retards sur le lancement des innovations de plus en plus difficiles à accepter;
• Un budget informatique qui croit aussi vite, sinon plus, que le chiffre d'affaire;
• Des difficultés croissantes et une réticence à faire évoluer les services automatisés
au rythme des besoins de l'entreprise;
• Etc.
1 de 273
Pourtant, les informaticiens s'efforcent tous les jours d'y porter remède et l'informatique
s'enrichit constamment et prend une importance de plus en plus importante dans tous
les secteurs. Les technologies de l'information ont créé de multiples opportunités de
différenciation, de productivité et de qualité, inimaginables avant l'apparition des
innovations sur lesquelles elles s'appuient. Elles ont, pour ce faire, accumulé à un
rythme soutenu des progrès énormes dans la puissance des unités centrales, le débit
des réseaux de transmission, la facilité d'usage des terminaux, la simplicité du dialogue
homme-machine ou la cohérence des architectures techniques. Les méthodes et les
outils d'analyse, de conception, de développement, de test, de prototypage ou
d'exploitation se sont intégrés, adaptés, simplifiés mais ont également foisonné.
Parallèlement, les unités informatiques se sont structurées et enrichies de nouvelles
unités de système d'information, d'architecture fonctionnelle et technique, de contrôle
qualité, de sécurité des opérations, etc. Leur rôle et leur position n'ont fait que se
renforcer pour se retrouver, dans bien des cas, au même niveau que les unités
fonctionnelles métiers.

Alors pourquoi le décalage ressenti entre ces deux familles (celle qui utilise l'outil
l'informatique et celle qui conçoit et construit cet outil) demeure-t-il persistant ?

Tout d'abord les objectifs, les préoccupations et les cycles de développement adoptés
par chacune des deux familles ont été construits et enrichis indépendamment, en totale
dissociation, depuis que l'informatique a fait son apparition dans les entreprises. Puis,
en conséquence, les langages utilisés dans l'un et l'autre monde pour dialoguer, décrire,
agir et archiver les opérations réalisées, se sont séparés et n'ont plus de
correspondance simple et naturelle. Les concepts sur lesquels ils se fondent diffèrent
tant par leurs contenus que par leurs frontières. Enfin, si des concepts comme le
processus, le métier et ses compétences ou l'activité et ses tâches, possèdent un sens
et une différenciation clairs dans le monde des métiers, il a toujours été périlleux de
trouver ou de bâtir des concepts qui leur correspondent dans le monde des techniciens
de l'information. Ceux-ci ont conçu, au fil des années, des concepts comme l'application,
le programme, l'interface, l'architecture ou le réseau que les responsables métiers ont
fini par intégrer dans leur vocabulaire. Mais ils ont toujours eu beaucoup de mal à les

2 de 273
 associer à leurs propres concepts pour en comprendre les correspondances et en
déduire les répercussions de leurs évolutions sur les systèmes gérés et développés par
les techniciens de l'information.

En fait, les visions de ces deux familles ne sont ni disjointes ni contradictoires car elles
représentent la même réalité opérationnelle mais selon des points de vue et des
concepts différents. Ne s'attaquer qu'à la vision organisationnelle donne les échecs
cuisants du « Business Process Reengineering » (BPR) chaque fois que dans cette
démarche on n'a pas impliqué simultanément et étroitement le Système d'Information.
Mais de la même façon, s'attaquer uniquement à la vision informationnelle provoque les
décalages que l'on sait, relatifs à l'inadéquation des outils informatiques aux besoins et
aux attentes de l'entreprise et de tous ceux qui seront appelés à les utiliser.

Afin de réduire cet écart dans les visions d'une même réalité, les organisations ne
peuvent se passer d'une approche qui englobe aussi bien le monde des métiers que
celui de l'informatique. Adopter une vision par processus métier, au lieu de celle par
projet, par application ou par besoin isolé, contribuera d'une part à instaurer un langage
commun à travers lequel les responsables métiers et les techniciens de l'information
communiquent et font correspondre leurs perceptions globales de la réalité
opérationnelle de l'entreprise et ses conséquences sur les visions organisationnelle et
informationnelle dont ils ont respectivement la charge et d'autre part, facilitera les
opérations de reconfiguration et de réadaptation pour faire face à l'évolution incessante
de l'environnement, aux exigences des clients, aux attaques de la concurrence et à
l'évolution rapide des technologies de l'information.

1.2. La problématique

Face à l'évolution incessante des systèmes d'informations et de leur complexité

croissante, l'enjeu, sans nul doute le plus important, pour l'administration québécoise
dans les années à venir, est de construire le « parfait » système d'informations ou du
moins maintenir un système d'informations cohérent, compréhensible, non impossible à
gérer et au sein duquel les labyrinthes ne conduisent pas à des impasses ou nulle part.

3 de 273
Toutefois, il faut bien se rendre à l'évidence, que le problème se trouve davantage
amplifié par la prolifération des méthodes utilisées pour modéliser les systèmes
d'informations et par la façon dont elles sont appliquées. Quoique certaines
administrations tendent comme elles le peuvent à structurer leur(s) système(s)
d'informations, la résultante suivante n'est pas une caricature, mais une fréquente vérité

• Des systèmes d'informations désordonnés : Souvent, bien que l'on parle de système
d'information, il n'y pas de système au vrai sens du terme : trop de redondances, un
désordre notoire, des applications qui ne conversent pas, des attributs et des
descriptions variant d'une application à l'autre, un référentiel quasi-inexistant, etc.
• Des applications juxtaposées : Elles ne reposent pas sur une philosophie de
réutilisation. Elles ont été conçues pour répondre à un besoin souvent urgent, par
des équipes distinctes et cloisonnées. Il en résulte pour l'utilisateur que les
ergonomies sont incohérentes : les touches de fonction changent de rôle d'une
application à l'autre, les menus déroulant et les raccourcis sont différents, les
ressaisies manuelles sont fréquentes. Et il en résulte pour l'administration des coûts
de maintenance et de développement exorbitants et une réinvention persistante de la
roue.
• Des complications inutiles : Les besoins sont exprimés de manière circonstancielle et
souvent à la verticale se limitant à un domaine particulier ou à un projet spécifique
sans une vue globale du système d'informations.

L'administration québécoise, considérée parmi les plus modernes de la planète, est

depuis longtemps consciente de cette problématique. Elle ne ménage pas ses efforts
pour structurer, améliorer et moderniser aussi bien le côté organisationnel que celui
informationnel. Cependant, l'héritage est souvent source de blocage à l'innovation : Peur
de remettre en cause tout l'investissement injecté, risque de « reformater » la base de
l'expertise acquise, risque de ralentir la productivité et l'octroi de services aux usagers
durant les phases de transition d'un mode de travail à un autre, etc. Le changement
dans la façon de faire en terme méthodologique dans une dimension pareille ainsi que
l'adaptation aux nouveaux concepts technologiques et organisationnels constituent, en
effet, des défis majeurs.
4 de 273
Heureusement pour répondre à ces défis, les technologies évoluent et apportent des
éléments de réponse. Les machines et outils de plus en plus puissants, sont des
éléments de réponse, mais la plus grande avancée et le plus grand potentiel de
productivité viennent très certainement de la technologie orientée objet. Après plusieurs
décennies de maturation, elle apporte une panoplie de concepts puissants et pleins de
promesses. Tous tournent autour de la promesse très motivante de la réutilisation et la
standardisation.

Si l'on part du principe qu'il faut changer pour s'adapter et qu'il faut adopter une nouvelle
méthode d'analyse et de conception à même de permettre à l'administration québécoise
de relever les défis cités auparavant, il n'en demeure pas moins que des questions
pertinentes se posent face à une telle option :
• Comment modéliser les processus métier ?
• Quel outil de modélisation choisir ?
• Comment passer du modèle métier au modèle informatique ?

Devant la panoplie de méthodes et langages présents sur le marché et presque tous

prétendant apporter la solution magique, le choix d'outils de modélisation métier adaptés
au contexte de l'administration semble donc très difficile. Il faut en effet que de tels outils
assistent les intervenants de tous les niveaux dans leurs tâches tout en répondant aux
critères suivants :
• Pouvoir être adaptés à différentes configurations informatiques;
• Offrir des services spécifiques à chaque catégorie d'intervenants, sous la forme
attendue;
• Pouvoir rapidement et facilement être mis en place et modifiés;
• Etre peu coûteux;
• Faciliter l'exploitation de modèles complexes, inévitables dans un tel contexte.
Si de telles exigences paraissent, de prime abord, être difficiles à concilier, les
technologies informatiques actuelles offrent des opportunités qui rendent possible la
mise en place de solutions adéquates. Une réflexion est cependant nécessaire quant à

5 de 273
 la manière de mettre en oeuvre ces technologies dans le contexte de la modélisation
des processus métier de l'administration.

1.3. Objectifs du mémoire

Le présent mémoire a pour objectif de proposer des concepts et une démarche

permettant de mettre en place des modèles métier au sein de l'administration et
d'aborder la notion de passage automatique d'un modèle métier vers un modèle
informatique tout en se penchant sur la manière de structurer les modèles métier de
façon à ce qu'ils soient évolutifs et adaptables à de multiples configurations
informatiques.
Nous proposons dans ce mémoire de :
• Dresser l'état de l'art dans le domaine des méthodes de modélisation des processus
métier;
• Dresser l'état de l'art dans le domaine des outils logiciels permettant le passage
automatique d'un modèle métier vers un modèle informatique;
• Décrire la méthode choisie de modélisation;
• Appliquer la méthode à un cas d'étude sur un processus métier du Ministère de
l'Éducation;
• Faire une évaluation des résultats obtenus;
• Faire des propositions d'amélioration de la méthode utilisée en cas de constatation
de lacunes.

1.4. Démarche

On doit bien sûr commencer par faire le tour de la littérature existante pour identifier les
études pertinentes et en faire une synthèse. On étudiera des méthodes et des outils
existants, notamment utilisés pour la modélisation de processus. On étudiera les
avantages, les contraintes et les limites liées à l'application de telles méthodes et outils
dans l'univers de la modélisation de processus métier.

6 de 273
 On vise à déterminer parmi les méthodes étudiées celle qui s'adapte le mieux au
contexte de l'administration québécoise et appliquer cette méthode sur une étude de
cas choisi parmi les processus métier du Ministère de l'Éducation du Québec.
On fera une évaluation des résultats obtenus et on proposera des améliorations ou des
adaptations éventuelles de la méthode appliquée afin qu'elle soit davantage appropriée
au contexte de ce mémoire.

1.5. Structure du mémoire

Ce mémoire a été décomposé en 6 chapitres :
• Le chapitre 1 présente le contexte de l'étude et ses objectifs ainsi que la démarche à
suivre pour réaliser les travaux;
• Le chapitre 2 est consacré à la modélisation des processus métier et à la description
des principaux rôles des modèles pour mieux comprendre les mécanismes clés du
métier;
• Le chapitre 3 a pour but de présenter un échantillon des méthodes et des outils
disponibles sur le marché et traitant de la modélisation des processus métier, et de
s'en inspirer afin de proposer les principes d'une nouvelle méthode qui soit simple,
facile à utiliser et surtout applicable dans on intégralité.
• Le chapitre 4 décrit la méthode de modélisation proposée;
• Le chapitre 5 est une application de la méthode proposée à un cas réel afin de
permettre de détecter les points forts, les points faibles ainsi que la perception des
acteurs qui ont participé à l'application de la méthode;
• Le chapitre 6 est une conclusion générale qui rappelle le contenu de chaque partie
et les grandes lignes suivies au cours de ce travail et fait un bref retour sur les
méthodes de modélisation analysées en synthétisant les résultats dans un tableau
comparatif. Les apports et les limites des travaux sont soulignés ainsi que les
perspectives d'avenir.

7 de 273
CHAPITRE 2 : MODÉLISATION DES PROCESSUS MÉTIER

2.1. Introduction

L'objectif de cette partie est de parcourir la littérature pour définir la notion de processus
métier, d'en fournir quelques exemples ainsi que de décrire l'apport de la modélisation
en général et dans l'univers des processus métier en particulier.
Cette partie est structurée en 9 sections. La section 2 définit les notions « processus
métier » et « modèles » et fournit quelques exemples de processus métier. Cela
permettra de dégager les difficultés actuellement rencontrées quant à la compréhension
de ce nouveau terme de plus en plus à la mode. La section 3 est centrée sur le rôle des
modèles métier. Elle décrit l'importance des modèles dans la communication au sein de
l'organisation, dans la mise en relief des relations existantes au sein du métier et des
différentes vues dont peut faire objet un même métier par des acteurs différents
(gestionnaires, comptables, commerciaux, informaticiens...) chacun selon son pôle
d'intérêt. La section 4 aborde la modélisation des processus métier en termes d'objectifs
que l'on peut assigner à un modèle, à savoir ses capacités d'explication et de
description et son aptitude à guider l'action des différents acteurs. Les sections 5, 6, 7
énoncent, respectivement, d'autres profits tirés de l'approche « modélisation des
processus métier », en l'occurrence l'accroissement de la compréhension du métier
d'une manière autre que textuelle, l'amélioration des processus métier en identifiant les
voies possibles capables de les rendre plus efficaces et par conséquent plus rentables
et la conception de nouveaux métiers en concevant de nouveaux modèles basés sur
l'enrichissement d'objets déjà existants sous une forme ou une autre au sein de
l'organisation. La section 8 vise à préciser que la modélisation ne sert pas uniquement à
identifier le noyau des processus mais également à identifier les processus candidats à
la sous-traitance. La section 9 aborde les niveaux de modélisations et le concept de
méta-modélisation.

8 de 273
2.2. Notions de processus métier et de modèles

Le terme « processus » occupe de plus en plus une place importante dans le discours
traitant des systèmes d'informations, de la modélisation et de l'ingénierie des systèmes
en général. Les processus deviennent l'élément fondamental pour l'analyse, et ce, quel
que soit le domaine traité.
Mais qu'est ce qu' un « processus » ?.
Le terme processus vient du latin et signifie littéralement «aller de l'avant ». Dans un
usage général, il évoque l'idée d'une marche progressive, souvent selon un plan
déterminé à l'avance.
Cette idée de plan a été reprise depuis longtemps dans les systèmes d'information. Dès
les années 70, dans sa méthode BSP (Business System Planning) pour la planification
des systèmes d'informations, IBM définissait un processus de gestion comme un
ensemble organisé d'activités pour la production d'un résultat. La méthode Merise a
considéré le processus comme la réaction de l'entreprise à un type d'événement. Plus
récemment, le courant de la reconfiguration des processus définit le processus comme
un ensemble finalisé d'activités, orienté vers la production d'un résultat représentant une
valeur pour un client. Cette définition est intéressante, car elle vise à centrer
l'organisation des activités sur le service rendu au client, faisant passer au second plan
les contraintes et les frontières internes de l'entreprise.
Le dictionnaire terminologique résume bien ces différentes définitions en décrivant un
processus métier, tel que la vente, le marketing, la recherche et développement, la
fabrication et la gestion des ressources humaines, comme une suite cohérente
d'activités et d'opérations commerciales de l'entreprise avec des tiers, traduisant les
besoins des clients et les exigences de l'environnement de l'entreprise, et tenant compte
ou non des activités internes de l'organisation, de manière à les agencer selon une
logique de création de valeur.

Dans [9], les processus d'une organisation sont classés selon trois axes : les processus
métiers (ceux visibles de l'extérieur de l'organisation et qui sont présentés aux clients,
tels que la Gestion du marché), les processus support (ceux qui fournissent le support
nécessaire aux processus métier pour s'exécuter - ils ne sont pas visibles de l'extérieur,

9 de 273
tels que le Développement de systèmes informatiques) et les processus de gestion
(ceux qui fournissent les moyens de gestion des processus métiers - ils ne sont pas
visibles de l'extérieur, tels que le Pilotage).

Nous voyons que de toutes les définitions, il ressort qu'un processus métier se traduit
généralement par un ordonnancement finalisé d'activités mettant en jeu différentes
informations, différents acteurs et assurant un objectif fonctionnel (production de biens
ou de services). Les informations utilisées étant englobées dans un système
d'information plus ou moins structuré.
Ces systèmes d'information ne constituent plus aujourd'hui un simple support
secondaire aux métiers mais font plutôt partie intégrale de ceux-ci. Tous les métiers font
usage d'une forme ou d'une autre des technologies de l'information et il est important
que leur système d'information soit conçu pour les supporter au même titre que les
autres unités de support de l'entreprise.
Mais comment réconcilier les acteurs du métier et ceux qui conçoivent et construisent le
système d'information autour d'une vision fonctionnelle et informatique du métier ?
Comment instaurer un langage commun entre ces deux familles?
Pour répondre à toutes ses questions, il devient impératif, selon [10] de construire un
modèle métier, c'est à dire une vue simplifiée d'une réalité complexe ou autrement dit,
une représentation schématique sur comment fonctionne le métier sans tenir compte
des détails non pertinents. Il représente le point focal autour duquel le métier gravite et
auquel les opérations les plus pertinentes du métier s'attachent.
Différentes définitions ont été données au concept « modèle » mais elles gravitent
toutes autour d'une même signification, à savoir qu'un modèle est une structure logique,
mathématique ou graphique, représentant une partie de la réalité et utilisée pour rendre
compte d'un ensemble de phénomènes qui, bien que n'ayant pas de lien de causalité
univoque, possèdent entre eux certaines relations. Il ressort également que la notion de
modélisation s'applique à toute représentation ou transcription abstraite d'une réalité
concrète, quelle que soit la forme, physique ou abstraite, ou le langage utilisé (littéral,
graphique ou mathématique) et ce chaque fois qu'il est nécessaire d'obtenir une
représentation du réel simplifiée pour le rendre plus intelligible.

10 de 273
 Cependant, il faut demeurer conscient du fait qu'un modèle est une « chose » pensée,
conçue et élaborée par des acteurs (gestionnaires, comptables, commerciaux,
informaticiens...) ayant des vues du métier selon des perspectives différentes quoique
faisant partie de la même réalité. Ceci est tout à fait naturel et le modèle métier ne saura
résoudre complètement toutes ces différences. Le modèle métier fournira une vue
simplifiée de la structure métier et constituera une base de communication,
d'amélioration, d'innovation et définira les besoins nécessaires pour bâtir le système
d'information adéquat qui supportera le métier.

2.3. Rôle des modèles

Dans tous les jeux, tels que celui des échecs, nous savons que nous avons besoin
d'une stratégie ou d'un plan pour bien mener les opérations. Un mauvais plan est mieux
que « pas de plan ». Durant le jeu, tout ne se passe pas comme prévu mais un plan
permet de nous diriger dans la bonne direction et de pouvoir prendre une décision
facilement. Un joueur habile peut changer partiellement ou totalement son plan pour
s'adapter à une nouvelle situation, peut opter pour une alternative et peut également
anticiper sur les possibilités de son rival.

Le modèle métier agit comme un plan de conduite du métier en termes de prise de

décision dans le choix des buts prioritaires, dans l'obtention des ressources nécessaires
pour une activité donnée, dans les négociations avec les partenaires, etc. Il sert
également comme description de la façon dont le métier est exécuté et de support pour
introduire les changements et les améliorations dans les processus tels que la réduction
des coûts, la réduction des délais, l'amélioration de la qualité des produits et des
services. Un modèle métier peut aussi servir à anticiper et prévoir les changements
nécessaires pour maintenir le niveau de la compétitivité. Il est évident qu'un modèle ne
peut fournir toutes les réponses désirées mais, comme pour le joueur, il constitue une
stratégie élémentaire et incontournable d'action et de conduite.

Un autre avantage de la modélisation, et non des moindres, est que le modèle fournit
une représentation visuelle des fonctions et des relations existantes au sein du métier et

11 de 273
qu'il serait fastidieux d'expliquer et de comprendre autrement (à travers des textes ou
des discours).
Idéalement, un modèle devrait consister en un seul diagramme qui inclut tous les
aspects importants du métier. Mais ceci demeure, du moins à ce jour, impossible
compte tenu de la complexité des métiers et compte tenu des nombreux et différents
aspects englobés au sein du métier concerné et qu'un seul diagramme ne peut à lui
seul tous les capturer. Généralement, un modèle métier est composé de :
• Vues : Un modèle métier est illustré via un nombre de vues capturant chacune les
informations pertinentes d'un ou plusieurs aspects spécifiques du métier. Plusieurs
vues sont parfois nécessaires pour séparer les perspectives sans perdre l'information
capitale.
• Diagrammes : Chaque vue peut consister en un ou plusieurs diagrammes montrant
chacun une portion de la structure du métier ou une situation spécifique. Dans
certains modèles, plusieurs types de diagrammes sont utilisés pour représenter une
seule vue du modèle. Chaque type décrivant alors un aspect des mécanismes du
modèle. Un diagramme peut représenter la structure du métier (Organisation du
business), un autre peut refléter la dynamique des processus (collaboration et
interaction), etc. Les diagrammes contiennent et expriment les objets, les processus,
les règles, les buts ainsi que les différentes visions relatives au métier en question.

• Objets et processus : Les concepts du métier sont rapportés dans les diagrammes
à travers l'utilisation de différents objets et processus. Les objets sont les « choses »
du métier; et ces « choses » peuvent être physiques telles que des acteurs humains,
des machines, des produits ou abstraites telles que des créances, des instructions,
des services, etc. Les objets peuvent représenter aussi d'autres objets sur lesquels
ils détiennent des informations. Les processus, quant à eux, constituent les fonctions
du métier qui consomment, raffinent, produisent des objets ou utilisent des objets
pour en produire d'autres.
Quel que soit le mode de représentation, un modèle est toujours motivé par les objectifs
sous-jacents. À titre d'exemple, le désir de modéliser une maison est dans l'intention de
la construire et dans l'intention d'y habiter ou de la vendre. Les objectifs Construire-
Habiter et Construire-Vendre ne conduiront pas nécessairement à deux modèles finaux
identiques. Toutefois et naturellement, leur premier modèle n'ira pas chercher toutes les
12 de 273
 spécifications nécessaires à la construction de la maison mais donner seulement une
vue exploratoire pour comprendre et avoir une idée générale sur l'allure qu'aura la future
maison. Dans le même ordre d'idée, la modélisation d'un métier peut être faite dans le
but de comprendre ce métier comme elle peut être faite dans le but d'améliorer ses
fonctionnalités et il important de distinguer les modèles utilisés comme outils
d'exploration de ceux utilisés comme outils de spécification. Construire un système
d'information supportant, par exemple, le département de ventes, passe d'abord par la
modélisation de ce métier à des fins de compréhension et ensuite construire le système
d'information approprié à partir de cette compréhension. Les modèles facilitent la
compréhension et la communication inter-acteurs mais à condition de toujours garder à
l'esprit les objectifs du modèle.

2.4. Modélisation des processus métier

L'un des premiers réflexes lorsqu'on se trouve face à un concept aux dimensions
multiples, est d'essayer d'en élaborer un modèle de compréhension. J-L. Le Moigne
définit ainsi le processus de modélisation comme une " élaboration et construction
intentionnelle, par composition de symboles, de modèles susceptibles de rendre
intelligible un phénomène perçu complexe et d'amplifier le raisonnement de l'acteur
projetant une intention délibérée au sein du phénomène " [1]. Les deux objectifs que l'on
peut assigner à un modèle sont d'une part ses capacités d'explication, de description ou
de compréhension (modèle destiné par exemple à interpréter des comportements
observés ou à partager un univers de discours), et d'autre part, son aptitude à guider
l'action (conception, simulation, contrôle/commande, etc.). Un modèle est donc " une
structure conçue, capable de rendre intelligible une réalité donnée en ordonnant et en
mettant l'accent sur les entités ou les relations les plus significatives, de sorte à mieux la
connaître ou mieux agir sur elle " [2].

Un métier est par sa nature même un système complexe constitué de plusieurs unités
(par exemple unité de vente, unité de fabrication, etc.) et de leurs fonctions. Certaines
de ces fonctions, telles que la gestion des absences des employés par exemple, ne sont
pas spécifiques à une unité particulière mais peuvent être communes à plusieurs. La

13 de 273
méthode traditionnelle de documenter un métier est de dessiner un organigramme qui
divise le métier en un nombre d'unités selon un schéma vertical, quoiqu'on s'efforce de
mettre en horizontal les unités de même niveau. La documentation se limite à décrire
comment est bâti le métier et comment il est organisé. Cette méthode de documentation
ne met pas en évidence les processus du métier, les interactions horizontales, les
ressources sous-jacentes, les règles qui régissent le métier, les buts et non plus les
problèmes qui peuvent entraver la réalisation des buts.
Par contre, un modèle bien bâti peut capturer et documenter toutes ces informations. Il
peut servir comme assise pour de meilleures décisions dans le fonctionnement du
métier et pour une meilleure documentation lors de la définition des spécifications du
système d'information.

Dans le domaine de la modélisation des processus métier, plusieurs théories s'efforcent

d'expliquer et de montrer comment structurer et exécuter un métier. Quelques
standards, plutôt que des méthodes, existent dans ce domaine (on les verra dans les
chapitres suivants) et la plupart de la littérature se limite à décrire le métier au lieu de
fournir les bonnes techniques et les bons outils pour exécuter le métier. Le concept
central utilisé est le processus métier lui-même qui décrit ses propres activités et
comment ses activités inter-agissent avec les autres ressources (humaines et
matérielles) pour atteindre les objectifs. C'est là le dilemme majeur dans la
modélisation : Est-ce le métier qui guide le modèle ou est-ce le modèle qui guide le
métier ? Ce dilemme se trouve davantage amplifié par les limites de la modélisation, en
l'occurrence l'incomplétude et la précision approximative. En effet aucun modèle métier
ne peut prétendre une complétude et une précision totales simplement parce que deux
observateurs différents auront deux visions différentes sur le métier et deux perceptions
distinctes du modèle. Comme énoncé auparavant dans ce document, pour des raisons
de clarté et de lisibilité, le modèle ne peut pas et ne doit pas contenir tous les détails du
métier faute de quoi il deviendrait complexe et difficile à comprendre. Sans oublier que
même si on veut détailler au maximum, les restrictions des langages ou des concepts
utilisés pour construire un modèle ne permettent pas de capturer tous les détails
souhaités.
L'autre problème qui touche à la modélisation concerne les visions futures d'un métier,
c'est à dire les visions et les anticipations des gestionnaires et des analystes sur ce que
14 de 273
 pourrait devenir le métier en question dans le futur. Un modèle n'est pas censé fournir
uniquement un instantané de la situation actuelle mais également une vue du métier au
futur. La vue actuelle et celle du futur font généralement l'objet de deux modèles
distincts et ne sont pas nécessairement supportées par le même modèle à moins qu'il y
ait peu de différences. Or aucun modèle ne peut prétendre refléter exactement les
évolutions ultérieures du métier et ne peut par conséquent être exécuté tel qu'il a été
planifié. Le monde bouge constamment et ses changements, voire ses mutations,
peuvent sérieusement affecter les bases sur lesquelles le modèle a été bâti. À ces
aléas, ajoutons que quelle que soit la robustesse d'un modèle, il faut aussi s'attendre
lors de son implantation à une certaine forme de résistance, passive ou active, de la part
des employés et/ou de certains gestionnaires.

Malgré ces limitations et ces contraintes, les arguments suivants, pour produire des
modèles métier demeurent très forts :
• Mieux comprendre les mécanismes clés du métier;
• Instaurer un langage commun aux divers acteurs;
• Élaborer un système d'information adéquat, capable de supporter le métier;
• Agir comme base pour améliorer la structure actuelle et les opérations du métier;
• Montrer la structure d'un nouveau métier en montrant les nouveaux changements à
introduire au métier actuel;
• Identifier les opportunités de sous-traitance (Outsourcing opprtunities);

2.5. Comprendre le métier

Une des motivations premières de tout modèle est d'augmenter la compréhension du

phénomène étudié et de faciliter la communication. Un modèle visuel est un excellent
outil d'explication et d'assimilation, car il permet de transmettre clairement de
l'information plus que toute autre description textuelle ou orale. Il sert essentiellement à
des fins d'identification, de compréhension, de prévision et de communication. Les
modèles évoluent davantage lorsque les acteurs de la modélisation comprendront
encore mieux le métier en question et lorsque des changements interviennent au niveau
du métier lui-même ou de son environnement. De plus, une fois que le modèle a atteint

15 de 273
 une certaine stabilité, c'est à dire donnant une image claire sur les activités et les rôles
de chacun, il peut servir comme moyen d'informer et de former les employés sur ce
qu'ils doivent faire et comment le faire. Il offrira ainsi à l'ensemble des acteurs une vision
globale sur les composantes de leur métier et sur leur positionnement et responsabilités
par rapport à ces composantes : La compréhension est donc plus facile et les
ambiguïtés sont réduites.

2.6. Améliorer le métier

Le modèle métier peut aussi être utilisé pour améliorer le métier. Cette technique
appelée parfois « Amélioration des processus métier » plus connue sous l'acronyme
BPI (Business Process Improvement) [10] est utilisée pour identifier les voies possibles
capables de rendre le métier plus efficace et par conséquent plus rentable. Le principe
général de cette technique est qu'une fois le métier bien modélisé, il est alors analysé
dans le but de rechercher les opportunités d'enrichissement et d'amélioration. Le BPI
suppose que le métier change de manière incrémentale (amélioration étape par étape)
au lieu d'introduire des changements radicaux. Lorsqu'une nouvelle opportunité
d'amélioration est identifiée, un nouveau modèle métier est produit pour montrer l'impact
des changements et comment ils seront implantés. Mais avant d'implémenter le
nouveau modèle, il est primordial qu'un ensemble d'activités soient accomplies afin de
permettre une insertion en douceur des améliorations proposées. Parmi ces activités
notons principalement :
• Décrire les nouvelles procédures introduites et s'assurer du support administratif
pour leur mise en oeuvre;
• Informer, former et motiver le public affecté par ces changements en vue d'obtenir
leur adhésion;
• Modifier le système d'information de manière à supporter les nouvelles opérations du
métier;
• Négocier avec les partenaires (tels que les sous-traitants) pour savoir qui doit
s'adapter à ces changements.

16 de 273
2.7. Concevoir de nouveaux métiers

La modélisation métier peut également servir à créer de nouveaux modèles ne faisant

pas partie directement du métier mais ayant pour but d'explorer de nouvelles possibilités
et voir si elles pourraient s'imbriquer dans le modèle actuel. Les nouveaux modèles
peuvent déterminer si la structure organisationnelle actuelle, ses ressources et ses
systèmes d'information sont capables de supporter de nouveaux processus avec tout ce
que cela implique en termes d'acceptation, de réadaptation et de coûts.
L'intérêt de nouveaux modèles ne réside pas uniquement dans la création de nouveaux
processus métier, mais aussi dans la possibilité de copier, étudier et analyser les
processus des concurrents en vue de se comparer avec ceux qui oeuvrent dans le
même domaine (une sorte de benchmark).

Souvent les nouveaux métiers sont conçus en se basant sur une vision de nouvelles
opportunités à exploiter. Modéliser cette vision suppose un premier test pour mesurer la
faisabilité et recueillir des informations telles que étude du marché, coûts, profits
attendus, etc. Ainsi, un nouveau modèle servira comme base incontournable de
définition des spécifications des buts projetés par le nouveau processus métier, des
ressources nécessaires, des nouveaux rôles des intervenants et également les façons
de mener l'intégration du nouveau processus métier à l'actuel.
En général, les nouvelles opportunités proviennent de la combinaison ou de
l'enrichissement d'objets déjà existants sous une forme ou une autre au sein de
l'organisation. Par exemple un métier peut identifier une autre utilisation des
informations qu'il détient sur ses clients pour leur proposer de nouveaux produits ou de
nouveaux services. En visualisant ces nouveaux processus à travers des modèles, il est
plus aisé de détecter les points forts et les points faibles du métier et ainsi agir
facilement pour en éliminer les premiers.

2.8. Sous-traiter les métiers non rentables

Externaliser ou « outsourcer » [[11], [12]] des activités de l'entreprise consiste à les

confier à un prestataire externe selon des modalités et des performances décrites dans

17 de 273
 un contrat de service. Une telle prestation s'accompagne le plus souvent du transfert, de
l'entreprise vers le prestataire, de tout ou partie des moyens de production et des
ressources humaines qui étaient précédemment affectés à ces activités. C'est pourquoi
tout projet d'extemalisation comporte a priori trois volets : l'organisationnel (métiers et
processus), l'informationnel et le volet dédié aux ressources humaines.
Si cette nouvelle terminologie s'impose aujourd'hui, la simple sous-traitance est en fait
de tradition fort ancienne dans les milieux industriels et de services. Toutefois, avec le
temps, la nature de l'engagement réciproque s'est progressivement enrichi et
transformé pendant que son ampleur, ses impacts et sa durée se sont significativement
accrus. Tout d'abord, l'exigence qui portait à l'origine sur la mise à disposition de
moyens a évolué vers celle de résultats et de performances le plus souvent
opérationnels. Ensuite, l'idée d'extemalisation est née dans des domaines à faible
valeur ajoutée comme le traitement du courrier, l'exploitation des systèmes
d'information, le transport ou la maintenance industrielle. Mais elle a fait son chemin et a
vu, depuis quelques années, son champ s'étendre et se diversifier vers des processus
plus complets comme la facturation, le traitement de documents ou la logistique, voire
même des activités, très en amont, de recherche et de développement. Elle couvre
désormais des pans de plus en plus importants et vitaux de l'entreprise allant jusqu'à la
délégation à des prestataires de processus complets et d'activités pourtant qualifiées, il
n'y a pas encore si longtemps, de stratégiques par les entreprises.

Dans ce contexte, la modélisation ne sert pas uniquement à identifier le noyau des

processus mais également à identifier les processus candidats à l'outsourcing. Le
modèle agit comme spécification sur la contribution de la sous-traitance, sur ses
frontières et sur son positionnement par rapport aux autres processus de l'organisation.
Il montre, telle une carte, l'intégration des différents processus en indiquant ceux qui
sont sous-traités et ceux qui ne le sont pas [10].

2.9. Niveaux de modélisation

Dans le cadre de la modélisation et comme mentionné au paragraphe 2.2, les différents

acteurs de l'organisation (gestionnaires, comptables, commerciaux, informaticiens...)
ont des vues du métier selon des perspectives différentes, quoique faisant partie de la

18 de 273
même réalité. Une telle situation conduit nécessairement à la construction de modèles
différents qui seront utilisés par des outils différents (spécifiques à chaque domaine :
comptabilité, qualité, planification, etc.) avec la contrainte d'uniformité (au niveau
formalismes) et la possibilité d'échange d'information inter-modèles. Pour ce, des
travaux sur la modélisation et la méta-modélisation ont été effectués par les groupes de
travail des différents organismes de normalisation (Meta Object Facility (MOF) [3], UML
[4], graphes conceptuels [8]) et par les groupes intéressés par l'échange de modèles [7]
ou la transformation de modèles [6]. Les besoins de langages communs et les besoins
d'échange d'information entre les outils de modélisation ont conduit à une réflexion sur
les objets de la modélisation, c'est-à-dire les métamodèles [5]. Aujourd'hui, il y a
consensus [[3], [4], [7]] sur une architecture à quatre niveaux (Figure 1) :

• Méta-métamodèle,
• Métamodèle,
• Modèle,
• Données.

Le méta-méta-modèle représente le niveau le plus abstrait, il représente le langage de

définition des méta-modèles. Il définit les notions de base qui vont permettre la
représentation de tous les autres niveaux ainsi que de lui-même. Des exemples sont
MétaClasse, MétaAttribut et MétaOpération dans le cas de UML; MétaEntité avec
(méta)attribut et MétaRelation avec (méta)attribut pour CDIF (CASE Data Interchange
Format); et concept, relation conceptuelle et graphe pour les graphes conceptuels.
Le méta-modèle définit le langage de représentation ou formalisme des modèles. Des
exemples sont Classe, Attribut, Opération pour UML; Entité, Attribut, Relation pour le
formalisme Entité-relation; et Type de concept, et Type de relation pour les graphes
conceptuels.
Le modèle définit le langage de représentation du domaine étudié. Des exemples sont
Organisation, Employé, Produit, Mission.
Les données sont des instances des types du modèle. Elles correspondent aux objets
du monde que l'on décrit. Des exemples sont Université-Laval, Jacques Tremblay,
Vendre des cellulaires.
Chaque niveau de modélisation est alors une instance du suivant.

19 de 273
 Méta-méta modèle

Meta modèle

Modèle

Données

Figure 1 Architecture à quatre niveaux [3]

2.10. Techniques de méta-modélisation

Un méta-modèle est un langage permettant de décrire un domaine d'intérêt particulier.

Par exemple, UML (Unified Modeling Language) [3] est un méta-modèle dédié à la
description des artefacts logiciels à objets. Un méta-modèle contient un ensemble de
concepts, de relations entre ces concepts, et de contraintes.
Ainsi UML introduit, entre autres, les concepts de classes, d'attributs, d'associations et
de méthodes. Ces méta-modèles vont permettre de définir des modèles, servant eux-
mêmes à décrire des instances. Il est communément admis que le méta-modèle est du
niveau du domaine, le modèle de celui de l'application, et l'instance de celui du
phénomène particulier et observable.

20 de 273
 Mëla-m«am«sdéte Entité,
<MOF}
Paquetage

,t
Mélamodèle
Méthode.

Modèle Client
roLIl iwaeui, j
Ficha

.t
Instance Jean Dupant
Soft-Maihl
FteheOOl
LJ
Figure 2 L'architecture quatre couches [3]

Le paysage de la méta-modélisation a beaucoup changé au cours des dernières

années. La majorité de ces évolutions ont été réalisées par l'OMG (Object Management
Group). Un premier aboutissement est le MDA (Model Driven Approach) (cf. Annexe 1),
nouvelle approche du génie du logiciel dans laquelle l'OMG entend instaurer la primauté
des modèles dans le système d'information et séparer les aspects purement métier des
considérations propres à la plate-forme d'exécution. L'OMG s'est beaucoup concentrée
sur l'interopérabilité des composants logiciels exécutables. CORBA (Common Object
Request Broker Architecture) s'inscrit dans cette catégorie. CORBA définit les
spécifications d'un middleware permettant de faire interagir des programmes en
langages hétérogènes. L'OMG a aussi mis au point le langage IDL (Interface Définition
Language) dont le but est de définir des interfaces de manière normalisée. IDL est doté
d'un certain nombre de spécifications de mapping (mise en correspondance) entre le
langage pivot et les principaux langages de programmation (Java, Cobol, C++ ...).
D'autres spécifications propriétaires (Java/RMI, EJB, COM+) concurrentes à celles
d'IDL ont été proposées. Elles sont moins ouvertes car elles obligent l'utilisation d'un
langage unique ou d'une plate-forme particulière. Toutefois, ces différentes alternatives
se bornent à l'interopérabilité des objets à l'exécution.

Par ailleurs, l'émergence d'UML (Unified Modeling Langage) en 1997 a été un tournant
dans la stratégie de l'OMG. Avec UML on est passé du niveau des composants
implémentés, où différents langages peuvent coexister, à celui de la modélisation, où

21 de 273
chaque composant peut être exprimé en UML. L'intérêt d'UML est qu'il permet
d'introduire plus d'informations que les interfaces d'IDL. Ainsi, au niveau d'UML, on peut
définir des contraintes explicites via le langage OCL (Object Constraint Language) et
également des aspects comportementaux (diagrammes d'état, séquence, collaboration).
Cependant, l'univers d'UML est limité à la représentation des artefacts utilisés lors du
développement des logiciels. Il ne prend pas en compte la définition du processus
logiciel et organisationnel. De ce fait, UML est simplement un méta-modèle parmi
d'autres.
Et afin de se prémunir contre la multiplication de méta-modèles, l'OMG a adopté le MOF
(Meta Object Facility) en 1997. Le MOF est un méta-modèle unique qui fournit un
langage de base pour la définition des méta-modèles. Alors que CORBA, par exemple,
permet l'interaction entre composants à l'exécution, le MOF permet d'établir des
relations entre modèles. Le MOF se situe donc à un niveau d'abstraction supérieur à
celui de CORBA. Ainsi, on peut décrire les liaisons entre des systèmes hétérogènes dès
la phase d'analyse ou de conception au lieu de les définir uniquement au niveau du
système implémenté. Notons que les interfaces IDL ont été définies pour la
manipulation des modèles basés sur des méta-modèles MOF.

,bvi I

I I
CORBA, IDL, HOP
1
1 ('«bol
UML 1

MOF.XMI
11
I I
I CWM 1SFEM

Figure 3 Les deux bus d'interopérabilité de l'OMG [3]

Avec l'émergence de la notion de méta-modèle, on assiste à une transition

technologique de la programmation à objets vers les modèles, de l'OMA (Object
Management Architecture) vers le MDA (Model Driven Approach). Ce dernier se base
sur le MOF et UML. Il se base également sur XMI (XML Metadata Interchange) qui
fournit les spécifications pour la sérialisation et l'échange de modèles et de méta-
modèles en XML. Ainsi que sur CWM (Common Warehouse Metamodel) qui définit des
structures de données (base de données relationnelles, schéma XML, Data Division

22 de 273
cobol, ...). UML permet, quant à lui, de construire, de visualiser et de manipuler les
modèles. Les référentiels du MOF offrent les services de stockage et XMI ceux
d'échange d'information. Enfin les systèmes existants peuvent être intégrés par
l'intermédiaire de CWM.

L'un des objectifs du MDA est de garantir la stabilité du système d'information face aux
évolutions technologiques. Cette stabilité est assurée par la séparation des informations
métier des considérations spécifiques à la plate-forme d'exécution via des PIM
(Plateform Indépendant Model) et des PSM (Plateform Spécifie Model). Un PIM est un
modèle défini en utilisant UML ou un autre méta-modèle et qui est indépendant des
plate-formes d'exécution, donc ne relatant que les informations métier de l'entreprise.
Par contre un PSM est la projection d'un PIM vers une plate-forme particulière. Un PSM
peut être défini en utilisant un profil UML spécifique tel que le profil UML pour CORBA
[13]. I! peut également être défini sous forme d'interfaces dans la plate-forme cible, par
exemple des interfaces IDL si CORBA est la plate-forme d'exécution. Le but est de
séparer le modèle initial, basé sur les invariants du système considéré, de sa
conversion vers une cible d'exécution donnée. En effet, le passage d'un PIM vers un
PSM est automatisé du moins partiellement. Les techniques de transformation de
modèles et de génération de code vont donc occuper une place importante au sein du
MDA [14]. La part de code généré doit augmenter au fur à mesure que le MDA gagnera
en maturité et que les modèles soient plus enrichis et plus précis. Le référentiel
documentaire plus au moins consistant guidant l'informaticien dans ses développements
devient donc un réservoir de supports d'information réutilisables et pouvant être
exploités pour produire du code de manière automatisée. Le code d'implémentation
devient alors un produit dérivé du modèle.
Les figures [15] suivantes schématisent une telle transition.

23 de 273
 Méta-editeur

Meta- Langage
modeling pour modehser — méta-modèle du domaine
le domaine
Expert
(domain du domaine
modeling) \
Editeur
graphique
pour modéliser
l'application
(Spécifie)
Modèle
application de l'application
modeling L'équipe qui conçoit
l'application

Figure 4 Le système du point de vue de l'utilisateur [15]

]VMta-editeur

Experts
Langage inplémenteurs
rjourmodâiser
1 înplementation — méta-modèle dïrrplémentation
Transfcrrration
automatique entre modèles

Modèle Qxle
d'inplérentation
de l'application exécilabe
\ /

Figure 5 Le système du point de vue du développeur [15]

24 de 273
2.11. Apports de la méta-modèlisation

Au sein d'une même entité organisationnelle, les différents acteurs n'ont pas toujours
(pour ne pas dire jamais) le même point de vue sur la notion de processus, chacun
évoluant dans son univers de compétence et chacun ayant son (ou ses) méta-modèle
spécifique. Le financier est plus intéressé par les coûts, le qualiticien par les procédures
et leur définition, le chargé du projet par la planification et l'affectation des ressources,
l'informaticien par l'automatisation et l'intégration des composantes logicielles, etc. Des
points de vue apparemment complètement disjoints mais, en réalité, ils constituent une
représentation des différents aspects d'un même et unique système.

Contrôleur de
gestion

Qualiticien

Organisateur

Chef de projet
""\ U
Informaticien

Figure 6 Différents points de vue sur les processus [1]

II est donc nécessaire que chacun d'entre eux dispose de l'environnement le plus
adapté à ses besoins. Il existe de nombreux produits ciblant un aspect particulier du
processus (qualité, coût, planification, automatisation, etc.). Chacun de ces outils se
base sur un formalisme particulier. Toutefois, de nombreux recoupements existent entre
ces formalismes. Il convient donc de pouvoir les identifier afin d'optimiser la saisie de
l'information et sa circulation entre les différents acteurs.
Les techniques de méta-modéjisation constituent une des réponses possibles à ce
problème. Un méta-modèle contient un ensemble de concepts et d'assertions qui vont

25 de 273
 définir la façon dont un modèle sera extrait d'un système. Il peut ainsi être considéré
comme un filtre qui ne retiendrait du système considéré qu'un certain nombre d'aspects
jugés pertinents. Le modèle obtenu sera différent selon le méta-modèle que l'on aura
utilisé pour décrire le système.
La méta-modélisation ne constitue pas une solution miracle aux nombreux problèmes
de l'ingénierie de processus. Au contraire, l'introduction des méta-modèles explicites
soulève un certain nombre de nouvelles questions. Par exemple, puisque chaque acteur
est concerné par la définition de processus et des tâches qui les composent, à qui
incombe la charge de leur identification ? L'apport principal de la méta-modélisation
consiste justement à identifier et expliciter ces nouveaux problèmes.

2.12. CONCLUSION

Nous avons évoqué dans ce chapitre la problématique de la modélisation en

commençant par une définition des notions de processus métier et de modèles et une
description des principaux rôles des modèles pour mieux comprendre les mécanismes
clés du métier, instaurer un langage commun aux divers acteurs, élaborer un système
d'information adéquat, capable de supporter le métier, agir comme base pour améliorer
la structure actuelle et les opérations du métier, montrer la structure d'un nouveau
métier en montrant les nouveaux changements à introduire au métier actuel et aussi
identifier les opportunités de sous-traitance (Outsourcing opprtunities).

Enfin, nous avons abordé les différents niveaux de modélisation de l'activité de

l'entreprise dans ses dimensions conceptuelle et organisationnelle. Le but recherché par
le dirigeant sera non seulement de concevoir son système d'information mais d'une
manière plus large, de modéliser le fonctionnement de son entreprise dans sa
dynamique et sa complexité, d'analyser ses risques, de concevoir sa stratégie pour
changer son organisation et améliorer sa compétitivité.
Les cinq bonnes raisons de modéliser l'activité de l'entreprise sont les suivantes :
• Expliquer son fonctionnement (approche dynamique par rapport à la statique de
l'organigramme);

26 de 273
• Concevoir son système d'information (intégrant les objectifs, les besoins, son
fonctionnement en interactions avec l'environnement);
• Mettre en évidence ses risques d'origine interne (dysfonctionnements générés par
son propre processus) et d'origine externe (par l'interaction de son système plongé
dans un environnement);
• Réfléchir à des changements de son organisation (support de diagnostic, outil
thérapeutique de remède aux défaillances détectées et de pronostic pour les
investisseurs et assureurs);
• Concevoir sa stratégie (éclairée d'une compréhension des mécanismes d'interaction
avec son environnement administratif, financier, social, technique et culturel) pour
repositionner l'entreprise dans cet environnement.

L'approche sera différente selon la culture et les objectifs des responsables, l'éclairage
sera fonction des sous-systèmes repérés tels des acteurs responsables (l'équipe
dirigeante), des domaines d'activité (les fonctions par nature), des processus (la chaîne
des actes de l'entreprise, les tenants et aboutissants),
Par ailleurs, l'informatique a connu des succès impressionnants dans de nombreux
domaines notamment dans toutes les opérations reposant sur la modélisation.
Aujourd'hui, de nombreux travaux, notamment ceux des organismes de standardisation
tel que l'OMG, convergent dans la recherche de méthodes et d'outils facilitant la
modélisation, l'échange inter-modèles, l'automatisation de la transformation des
modèles d'un niveau à l'autre et ce en cherchant à les rendre indépendants des plate-
formes matérielles et à normaliser les formalismes utilisés et les processus de
modélisation.
Cependant, la prolifération de méthodes et d'outils ne facilite guère le choix. Les
questions ne manquent pas : Comment comparer deux méthodes (ou deux outils) dont
les descriptions commerciales sont quasi-identiques ? Dans quel contexte s'applique
telle ou telle méthode ou tel outil ?, etc. C'est ce à quoi nous allons essayer de répondre
dans le chapitre qui suit, en présentant les caractéristiques fondamentales d'un
ensemble de méthodes et d'outils de modélisation, en établissant un cadre de
comparaison et en décrivant les points forts et les points faibles de ces méthodes et ces
outils.

27 de 273
CHAPITRE 3 : MÉTHODES ET OUTILS
3.1. Introduction
L'évolution et l'expansion incessantes de l'informatique, la complexité de plus en plus
accrue des systèmes d'information, la volonté de l'utilisateur final de s'affranchir d'une
organisation informatique souvent taxée de « lente à répondre » à ses besoins de plus
en plus changeants et bien d'autres facteurs imposent aux entreprises en général et aux
administrations en particulier une bonne maîtrise de leurs processus métier. Ceci
implique une nouvelle approche des produits-services et des types de prestations de la
profession où le sens du service, de l'organisation, de l'économie et de l'innovation sont
entremêlés et fédérés au bénéfice des entreprises qui découvrent une nouvelle
compréhension du métier : l'ingénierie des systèmes d'information est née. Ce concept
nouveau touche aussi bien la qualité exigée des produits que les procédés et
comportements nécessaires pour les obtenir.
La concurrence augmente et la technologie "galope" avec son cortège de rêves,
d'espoirs et de désillusions. L'interconnexion des systèmes de gestion, les avancées
techniques du temps réel et du transactionnel, la réalité des bases de données puis des
réseaux, tous ces faits nous mettent dans l'obligation de traiter à la fois l'instabilité,
l'évolutivité et la complexité qui en résultent. Il devient alors nécessaire de privilégier les
approches où la prise en compte du "global" est préférable à la précision du détail. La
pensée analytique, basée sur le fonctionnement, cède le pas à la puissance des visions
plus synthétiques, plus itératives, fondées sur des modèles représentatifs, flexibles et
compréhensibles par les divers acteurs.
L'historique de la profession informatique montre assez bien que l'on est passé
progressivement de l'univers des applications autonomes à celui des applications
imbriquées, du traitement automatisé des procédures administratives ou industrielles à
l'aide à la décision, du traitement par lot au traitement transactionnel, des techniques
hiérarchiques aux techniques relationnelles. Tout cela augmente la complexité des
systèmes tant du point de vue technique que fonctionnel. Ces systèmes ne sont plus à
la dimension d'un seul individu, mais à celle d'équipes pluridisciplinaires, disposant

28 de 273
d'une forte culture collective, dont le jeu à somme positive permet d'obtenir un haut
niveau de performance.
Si la nécessité du travail en équipe apparaît clairement, sa mise en pratique n'est pas
courante, ne serait-ce que parce que la performance individuelle est fréquemment
opposée aux vertus du travail en groupe. La spécialité et l'expérience de chacun y sont
souvent prioritaires et peuvent conduire à des pratiques et à des méthodes différentes.
Le travail en équipe requiert que chaque acteur y soit reconnu à égalité, ce qui impose
des modes de fonctionnement différents de ceux communément admis. Dans le monde
de la modélisation des processus métier, comme d'ailleurs dans tous les domaines, une
méthode utilisable par tous est non seulement nécessaire mais fondamentale pour un
meilleur rapprochement des vues des différents acteurs, pour une transmission
organisée et une réutilisation du savoir-faire, pour disposer d'un « guide » du comment
modéliser et bien entendu pour éviter de modéliser n'importe comment. Des méthodes
de travail éprouvées et reconnues doivent remplacer les diverses recettes locales.
Le besoin d'une méthode provient aussi des multiples facettes mises en oeuvre lors de
la construction d'un système:
• La difficulté d'expression des besoins, leur traduction dans une forme
compréhensible, si possible non ambiguë, et leur satisfaction en fin de compte;
• Le nombre élevé de constituants du système à réaliser qui nécessite la maîtrise de
leurs interactions et de leurs compatibilités;
• La variété de contraintes à prendre en charge, qu'elles soient d'environnement, de
production ou d'utilisation;
• La multiplicité des points de vue des divers acteurs concernés par la vie du projet ou
du produit avec tout ce que cela suppose en matière de maîtrise d'organisation et de
structuration d'équipes pluridisciplinaires;
• Le nombre élevé de tâches à réaliser dans un ordonnancement rigoureux, ce qui
impose à la fois du savoir, du savoir-faire, du faire-savoir et du savoir-être.

Cependant, devant la panoplie de méthodes, outils et langages présents sur le marché

et presque tous prétendant répondre à tous les besoins de modélisation, le choix d'outils
de modélisation métier adaptés au contexte de l'administration semble très difficile.
L'objectif de cette section est de présenter un ensemble de méthodes et d'outils de

29 de 273
 transformation inter-modèles actuellement sur le marché, d'essayer d'établir une
comparaison entre les méthodes d'une part et entre les outils d'autre part. Selon le
contexte de l'étude, nous nous limitons par la suite, à déterminer laquelle des méthodes
s'adapte le mieux au contexte de l'administration québécoise.

3.2. Méthodes de modélisation

Au fur et à mesure de l'évolution des langages et des méthodes de programmation,

plusieurs grandes générations se sont succédées. La première prend ses origines au
début de l'histoire de l'informatique, à l'époque des langages procéduraux et
fonctionnels. On peut discerner deux langages majeurs qui ont marqué cette période : le
Cobol (1959) et le C (1972) (encore très largement utilisé). L'évolution des langages a
ensuite été guidée par un soucis constant d'améliorer la productivité, la réutilisabilité et
la facilité de maintenance et d'évolution des logiciels. Parallèlement à l'évolution des
langages, les systèmes de gestion des données ont connu eux aussi une avancée
notable en passant des systèmes de fichiers classiques (jusqu'aux années 60) a celui
de SGBD en réseau et hiérarchique (fin des années 60) puis à celui de SGBD
relationnel (à partir de 1970) et vers un SGBD orienté objet (à partir des années 80).
A la suite de la constatation d'une stabilité plus forte en se concentrant sur les entités du
système plutôt que sur ses fonctionnalités, la programmation orientée objets a été
privilégiée. Le premier de ces langages fut le Smalltalk (1976), suivi du bien connu C++
(fin des années 80). Aujourd'hui, le Java (1995) est de très loin le langage le plus
prometteur dans ce milieu (le C# n'étant que dérivé de Java).
Suite à l'évolution des réseaux (dont Internet) et à l'augmentation de la complexité des
logiciels, des architectures à base de composants ont vu le jour. Ces intergiciels se
caractérisent par une vision plus macroscopique que l'approche objet. Un composant
est un agrégat d'objets formant un ensemble cohérent et autonome. Chaque composant
peut être distribué sur un réseau, ce qui leur permet de s'appeler entre eux sans se
rendre compte qu'ils peuvent être physiquement situés à l'autre bout de la planète. En
parallèle au développement des architectures à base de composants, un langage de
description de données connaît également un engouement sans réserve : le XML
(eXtented Markup Language) [16]. Celui-ci se voit ainsi utilisé dans tous les domaines et

30 de 273
 pour des utilisations assez variées. Porté par IBM, Microsoft et le W3C1, des protocoles
utilisant XML ont été mis au point pour décrire et permettre la communication entre
composants logiciels distribués sur Internet. Ces WebServices se servent ainsi de trois
protocoles majeurs : UDDI2 (annuaire), WSDL3 (description d'interfaces) et SOAP4
(communication). Grâce à l'utilisation de protocoles ouverts et standardisés, on retrouve
ici aussi l'indépendance vis à vis des langages, plateformes et fournisseurs d'applicatifs.
En résumé, on peut donc identifier (à titre indicatif) les différentes évolutions suivantes :

Famille Langages
procédural Fortran, Cobol, C
objet Smalltalk, C++, Java
composant CCM, DCOM, EJB
webservice UDDI, WSDL, SOAP
Tableau 1 Evolution des langages

Depuis maintenant quelques années, le concept de programmation orientée objets

(POO) a évolué pour regrouper plusieurs objets de même catégorie. Ceci permet une
forte séparation des modules d'un programme et une grande réutilisabilité. De plus, ces
groupes d'objets peuvent être facilement déployés sur des machines distantes, et
communiquer ensemble de manière transparente. Cette approche est nommée : la
conception orientée composants. Des frameworks de composants ont été mis en place
pour simplifier et uniformiser la conception de composants. Sur plate- formes Windows,
Microsoft a ainsi créé les composants COM, puis DCOM, leur équivalent en
environnement distribué.
En plus de l'évolution des langages et des composants, les méthodes de conception se
sont raffinées au fur et à mesure du temps. Pour les langages procéduraux, la méthode
à la mode était SADT(SofTech USA) [17]. Cette méthode générait beaucoup de
documents et partait du principe de boîtes noires et de raffinements successifs. Du côté
des bases de données, la domination de Merise [18] a été longtemps incontestée
(surtout en France).

1
W3C : World Wide Web Consortium (http://www.w3.org)
2
UDDI : Universal Description Discovery and Intégration
3
WSDL : Web Services Description Language
4
SOAP : Simple Object Access Protocol
31 de 273
 Avec l'avènement de la programmation orientée objets, plusieurs méthodes sont
entrées en compétition. Plutôt que de disperser les concepteurs dans des méthodes
concurrentes avec pourtant les mêmes objectifs, les créateurs des méthodes OMT
(Object Modeling Technique) [19], Booch et OOSE se sont regroupés pour mettre en
place une spécification commune. C'est ainsi qu'est né UML (Unified Modeling
Language), standardisé peu de temps après (1997) par l'OMG (Object Management
Group) et qui est plutôt une syntaxe de représentation qu'une méthode et dont nous
parlerons plus loin dans ce chapitre.
On constate ainsi que l'histoire des systèmes d'information a connu (et connaîtra fort
probablement) de nombreuses évolutions et que la diversité des solutions adoptables
pour un même problème ne cesse d'augmenter. Dans ce contexte, les entreprises ne
veulent plus investir dans des intergiciels qui n'ont pas une pérennité assez élevée.
L'OMG (Object Management Group) pensait que Corba5 [20] était suffisamment ouvert
et puissant pour répondre à tous les besoins et qu'il allait devenir le standard universel,
comme l'est UML du côté des langages de modélisation. Pourtant, les générations
d'architectures de composants se succèdent, avec à chaque fois la nécessité pour les
entreprises de reformer leurs ingénieurs et de difficilement remettre à jour les
programmes développés.
De nombreux architectes ont déjà mis en évidence que quelle que soit la technologie
utilisée pour implémenter les composants, la logique métier reste la même. Il leur a
donc paru approprié de tenter de dissocier au maximum l'architecture technique de la
logique métier (en anglais, business logic). Leur but est le même depuis toujours :
réduire les coûts de développement en diminuant le temps de conception et en
augmentant l'évolutivité.
Pour standardiser les différentes tentatives dans ce sens, les architectes des plus
grosses compagnies d'informatique avaient besoin d'un organisme indépendant et
robuste. Ils ont donc logiquement chargé l'OMG (Object Management Group) de la
mission de définir une norme indépendante d'un intergiciel particulier.
Mais avec la croissance de la complexité des domaines d'application, le choix d'une
méthode de modélisation devient de plus en plus difficile. Une méthode qui a fait ses

5
CORBA : Common Object Request Broker Achitecture. Standard de gestion d'objets distribués, mis au point
par l'OMG

32 de 273
 preuves dans un domaine d'application peut être inadéquate dans d'autres domaines.
La situation d'ingénierie de chaque application est différente. L'expérience a montré que
les méthodes ne sont pas universelles et elles ne peuvent pas prévoir toutes les
situations possibles. Les méthodes classiques ne sont pratiquement jamais suivies à la
lettre. Les ingénieurs d'application sont souvent amenés à les adapter pour pouvoir les
appliquer dans le contexte de leurs projets [21]. De plus, les méthodes ne sont pas
toujours suffisamment flexibles pour être facilement modifiées et adaptées.
La section suivante a pour objectif de nous orienter vers le choix d'une telle méthode,
ou, le cas échéant, de faciliter la construction d'une nouvelle méthode plus pertinente à
partir de méthodes existantes.

3.3. Cadre de comparaison

Les méthodes d'ingénierie de systèmes sont généralement supposées être

indépendantes de la situation de leur application. Cependant, l'existence d'une multitude
de méthodes montre que chaque méthode a des avantages et des désavantages
relatifs au domaine du problème.
Pour pouvoir choisir et sélectionner de façon rigoureuse la ou les méthodes adéquates
les plus pertinentes, il faut pouvoir disposer d'un ensemble de critères de sélection,
c'est-à-dire d'un cadre comparatif qui permette de les confronter.
La difficulté de notre étude réside dans la définition d'un cadre de comparaison commun
à toutes les méthodes de modélisation de processus métier. La plupart des études se
préoccupent de comparer les méthodes au sens du génie logiciel ou de conception de
systèmes d'information. Nous essayons dans cette section d'en tirer des critères
similaires qui nous permettent de confronter les méthodes au sens de la modélisation
des processus métier.

Pour évaluer les méthodes et pour aider dans la sélection des méthodes, des
techniques de comparaison ont été proposées. Par exemple, Livary propose un cadre
de référence pour comparer les méthodes orientées-objet qu'il applique à six méthodes
[22]. Ce cadre divise le processus de développement des systèmes d'information en
trois niveaux : organisationnel, conceptuel et technique. Chaque niveau est analysé
sous trois vues différentes : structurelle, fonctionnelle et comportementale.

33 de 273
Dans le projet TOOBIS Souveyet et al. s'inspirent du travail de Livary pour comparer
des méthodes orientées-objet [23]. Dans ce travail, le cadre de référence de Livary est
complété par des relations entre les trois niveaux et les trois vues.
Song [24] et Hong [25] proposent des approches pour comparer des méthodes d'une
manière systématique. Ces approches sont basées sur la méta-modélisation des
méthodes à comparer. Elles proposent de construire tout d'abord les méta-modèles de
toutes les méthodes à comparer en utilisant le même formalisme, ensuite elles se
servent de ces méta-modèles pour comparer différents aspects de ces méthodes. Hong
[25] par exemple, compare les méthodes selon trois perspectives : les étapes d'analyse
et de conception, les concepts et les techniques. Une représentation tabulaire est
utilisée par les deux approches pour comparer les méthodes.
Rossi [26] propose une approche qui permet de mesurer la complexité des méthodes
d'une manière systématique et automatisée. Cette approche utilise un ensemble de
métriques permettant de mesurer, d'un côté, la difficulté de comprendre et d'apprendre
la méthode causée par le nombre de concepts (vocabulaire, démarche,
ordonnancement des activités, etc.) utilisés dans la méthode et d'un autre coté, la
complexité des produits causée par le nombre de propriétés des objets et des relations.

Rappelons que la mise en œuvre d'une méthode (sa méthodologie) décrit la façon dont
ses différentes phases s'enchaînent. Cette méthodologie doit être adaptée au domaine
auquel la méthode est destinée. Ainsi, pour modéliser une organisation, il est préférable,
pour des raisons de disponibilité des acteurs concernés, de procéder par phases
successives (comme dans le modèle en cascade par exemple), plutôt que par essai-
erreur (comme dans le modèle en spirale). En effet, le modèle en spirale nécessiterait
de consulter, à chaque nouveau prototype, l'ensemble des acteurs de l'organisation, ce
qui, dans le cadre d'une organisation composée de plusieurs dizaines de personnes
serait très coûteux en temps.
Les principales phases suivies par les méthodes sont Yanalyse de l'existant, la
modélisation, la spécification, la conception (englobant la conception architecturale et la
conception détaillée au sens du génie logiciel) et la validation technique. Nous omettons
délibérément la phase de réalisation qui concerne plus l'utilisation de langages ou de
logiciels spécialisés et ne faisant pas l'objet de ce mémoire. Les principaux modèles

34 de 273
utilisés par les méthodes pour enchaîner ces phases sont le modèle en cascade, en
spirale (au sens de Boehm [27]), en V, le modèle évolutif (dit aussi incrémental).

Dans le cas de systèmes complexes à étudier, les méthodes procèdent par couches
successives, soit par une approche descendante (ou top-down : l'organisation est
d'abord étudiée dans son ensemble, puis la méthode traite les cas particuliers),
ascendante (ou bottom-up : la méthode part des différents postes ou tâches, puis
remonte progressivement vers des ensembles tels que les groupes de travail, les
procédures ou les métiers) ou une approche évolutive (middle-out : cette approche
consiste à partir des groupes de travail pour ensuite descendre au niveau des postes ou
remonter au niveau de l'organisation).

Le choix d'une méthode peut donc être associé à huit (8) catégories de critères
fondamentaux :
• Cycle de développement : composé des sous critères cascade, spirale, en Y, évolutif
(Incrémental);
• Phases concernées : Analyse, Modélisation, Spécification, Conception, Validation
technique;
• Approche de développement : pouvant être descendante, ascendante ou évolutive;
• Degré d'implication de l'utilisateur : ce degré va de pas d'implication à implication
essentielle;
• Moment d'implication de l'utilisateur : celui-ci se situe au début, au milieu et/ou en fin
de cycle;
• Position de l'analyse : L'utilisation d'une méthode est fortement dépendante de ses
formalismes et de sa façon de représenter le problème auquel elle est dédiée. Cette
représentation peut être directe dans le cas où la représentation des données issues
de l'analyse est neutre (par exemple : les actigrammes de la méthode SADT
transcrivent directement les activités identifiées lors de l'analyse). Mais elle peut être
également interprétée. Dans ce cas, les données de l'analyse sont interprétées par
les auteurs lors de la modélisation (par exemple : transformation sous forme objet);
• Principe d'assemblage : Les méthodes peuvent également décomposer le système
auquel elles s'appliquent selon des niveaux d'abstraction (séparation en niveaux
conceptuel, organisationnel et physique), selon un axe généralisation-spécialisation

35 de 273
 (lorsqu'une organisation est étudiée, on peut partir du comportement des personnes
interrogées, puis abstraire la personne en l'associant à un rôle, puis à un groupe de
travail, dans le cas d'une approche ascendante), selon un découpage type-
occurrence (appelé aussi classe-instanciation dans les principales méthodes
orientées objet) ou selon une orientation stratégie-tactique (dans le cas d'un
département, il s'agit d'étudier ses stratégies à long terme, le pourquoi de l'activité,
ainsi que les tactiques, le comment);
• Les formalismes (schémas, concepts et règles) : ce critère énumère les formalismes
utilisés pour la représentation des données, des activités, des traitements et de la
dynamique utilisés par la méthode. Le nombre de formalismes utilisés est variable
selon les méthodes. Certaines réutilisent les mêmes formalismes pour les différentes
parties du système, d'autres suggèrent d'utiliser de nouveaux formalismes lors de la
modélisation de nouveaux concepts (par exemple, pour la modélisation du niveau
conceptuel et du niveau organisationnel).
Mais il est important de considérer d'autres critères qui portent sur la qualité de la
méthode de modélisation, à savoir :
• Flexibilité : la méthode doit être adaptable à un concepteur particulier et à un
contexte particulier;
• Coût d'acquisition;
• Complexité d'utilisation;
• Standard : la méthode constitue ou utilise-t-elle un standard reconnu ?
• L'environnement du système à modéliser influe également sur la réussite de la
méthode. Ainsi, certaines méthodes sont sensibles au degré de structuration (dans
certaines entreprises, les fonctions de certaines personnes ne sont pas cernées
clairement), à la stabilité du système (une entreprise en pleine restructuration pourra
être considérée selon ce critère comme instable) et/ou à la certitude des
informations recueillies lors de l'analyse (une analyse menée dans une entreprise où
les tâches ne sont pas précisément réparties conduit à des incertitudes concernant
les données recueillies).

36 de 273
Le Tableau 2, ci-après, résume l'ensemble des critères choisis.

Dimensions Critères
Cascade
Cycle de développement Spirale
Y
Incrémental
Analyse
Modélisation
Phases concernées
Conception
Validation technique
Descendante
Approche Ascendante
Evolutive
Pas
Peu
Degré d'implication de l'utilisateur Moyen
Beaucoup
Essentiel
Début
Moment d'implication de l'utilisateur Milieu
Fin
Interprétée
Position de l'analyse
Directe
Données
Principe de construction Activités
(ordre d'apparition des formalismes) Traitements
Dynamique
Niveaux d'abstraction
Généralisation /
Principe d'assemblage Spécification
Type / Occurrence
Stratégique / Tactique
Données
Activités
Formalisme
Traitements
Dynamique
Oui
Outils associés
Non
Oui
Standard
Non
Faible
Flexibilité Moyenne
Forte
Coût d'acquisition
Complexité d'utilisation Faible
Moyenne

37 de 273
 Dimensions Critères
Forte
Structuré
Semi-structure
Non structuré
Nature de l'environnement Stable
Instable
Certain
Incertain
Tableau 2 Critères de comparaison

3.4. Utilisation du cadre de comparaison pour l'évaluation

II est important d'étudier et de comparer les différentes classes de méthodes disponibles
et de voir dans quelle mesure celles-ci sont à même de modeliser les processus métier
d'une organisation. Cependant, compte tenu du nombre important de méthodes
existantes et de la difficulté (matérielle) de pouvoir toutes les comparer, nous nous
sommes limités à l'évaluation de huit méthodes, représentatives de quatre domaines
d'application différents. Ces domaines concernent particulièrement la mise en place de
systèmes de bases de données, la conception objet, la représentation structurée, la
modélisation d'organisation. Ces méthodes sont :
• MERISE [[28], [29]] : représentative des méthodes systémiques (au sens de Le
Moigne [30]), et dont la finalité est l'analyse et la conception de systèmes
d'information (reposant sur une base de données).
• OMT (Object Modeling Technique; [31]) : certainement une des plus représentative
des méthodes d'analyse et de conception orientées objets utilisée dans les
entreprises avant l'apparition de UML (cf. ci-dessous). Bien entendu, d'autres
méthodes bien connues auraient pu également être considérées, telles les méthodes
proposées par Booch [33], Coad et Yourdon [34] ou Jacobson [35].
• UML (Unified Modeling Language; [32]) : Langage de modélisation et de conception
unifiant (pour la représentation) les modèles présents dans les principales méthodes
orientées objets [[36], [37]]. Une comparaison sommaire avec OMT permettra de
constater si UML est mieux adapté à la modélisation d'organisations qu'OMT.
• SADT (Structured Analysis and Design Technique) [38] : inspirée des concepts
proposés par Ross [39], et représentative des méthodes dites cartésiennes ou
structurées, telle SA (Structured Analysis) [40], orientées vers les phases d'analyse
et de spécification.

38 de 273
 • OSSAD (Office Support System Analysis and Design) [41] : méthode d'analyse et de
spécification de systèmes d'information centrée sur l'organisation du travail.
• UP (Processus Unifié) [46] est un processus de développement logiciel « itératif et
incrémental, centré sur l'architecture, conduit par les cas d'utilisation et piloté par les
risques ». Son principe méthodologique peut également s'appliquer à la modélisation
des processus métier.
• 2TUP (2 Tracks Unified Process) de Valtech [49] est un processus UP mais en forme
Y. L'axiome fondateur de 2TUP a été le constat que toute évolution imposée au
système d'information peut se décomposer et se traiter parallèlement, suivant un axe
fonctionnel et un axe technique. La fusion des deux axes conduit à l'obtention d'un
processus de développement en forme de Y.
• GPS (Gestion des Parcours) : Élaborée en 2001 par la CSST (Commission de la
santé et de la sécurité du travail du Québec) la méthode GPS [50] a pour objectif
principal de fournir aux utilisateurs et aux développeurs un cadre de développement
unique pour tous les projets de la CSST et dans lequel les activités à réaliser
(appelées parcours) et les biens livrables sont clairement définis et limités en
nombre.

Notons, à titre d'information, qu'une initiative est en cours pour créer une méthode
standard pour la modélisation des processus métier, entre une entreprise et ses
partenaires, basée sur UML : UMM (Méthodologie Unifiée de Modélisation) de
l'UN/CEFACT6(United Nations/ CEntre for Facilitations of procédures and practices for
Administration, Commerce and Transport) [47]. Cette méthodologie est basée sur
l'adaptation du "Unified Process Methodology" développé par Rational pour répondre
aux besoins de l'UN/CEFACT. UML est la technique de modélisation utilisée [64].

3.4.1. La méthode MERISE

Le Tableau 3 montre les différents aspects pris en compte par la méthode MERISE et
permet de mettre en évidence les enseignements ci-dessous.
Dans MERISE, la représentation a une très grande importance. D'ailleurs, les
formalismes y sont essentiels, même si la méthode est quelque fois injustement

6
UN/CEFACT (Centre for Trade Facilitation and Electronic Business, sous l'égide de l'ONU).

39 de 273
résumée par certains développeurs à ses formalismes principaux : le Modèle
Conceptuel des Données (MCD), et à un degré moindre le Modèle Organisationnel des
Traitements (MOT). Le découpage en niveaux d'abstraction est très marqué. En
général, on retrouve, dans les différentes versions de MERISE, les niveaux conceptuel,
organisationnel et physique. Le système est d'abord abordé par les flux de
communication, puis les données et les traitements sont analysés en parallèle pour
ensuite être confrontés. En principe, les moyens fournis pourraient apporter un plus
pour la collaboration entre concepteurs et utilisateurs (cf. à ce sujet les travaux de
Barthet [[42], [43]], étendus par Tarby [44]).
MERISE considère l'organisation par ses échanges et ses actions (par le MCD et le
MOT). Cette méthode est destinée aux systèmes structurés, stables et certains, ce qui
n'est pas le cas dans différents domaines d'application (ou entreprises). De plus, sa
finalité orientée base de données permet d'avoir une information qualitative et
quantitative sur les données traitées dans l'organisation.

Le cycle de vie total du projet, supporte le développement en cascade et possède une

approche descendante. L'utilisateur est moyennement impliqué dans le projet et sa
contribution se situe surtout au début, au niveau des modèles conceptuels et
organisationnels.
Au niveau technologique, MERISE est destinée à la conception de bases de données
qui peuvent supporter un mode de traitement batch, interactif, synchrone et client-
serveur (suivant la version de MERISE). Elle peut aboutir à une programmation
structurée, mais surtout à la conception d'une base de données éventuellement orientée
objet (grâce aux extensions de MERISE; [45]).
En ce qui concerne la coopération, MERISE permet de représenter la communication de
données et la coordination (par son modèle de traitement), mais ne va pas plus loin
dans ce domaine.
Dimension Critères
Cascade X
Cycle de développement Spirale
Y
Incrémental
Phases concernées Analyse X
Modélisation X
Conception X

40 de 273
 Dimension Critères
Validation technique X
Descendante X
Approche Ascendante
Évolutive
Pas
Peu
Degré d'implication de l'utilisateur Moyen X
Beaucoup
Essentiel
Début X
Moment d'implication de l'utilisateur Milieu
Fin
Interprétée
Position de l'analyse
Directe X
Données 1
Principe de construction Activités 1
(ordre d'apparition des formalismes) Traitements 2
Dynamique
Niveaux d'abstraction X
Généralisation / X
Principe d'assemblage Spécification
Type / Occurrence X
Stratégique / Tactique
Données M.C.D.,
M.O.D.,
M.L.D.
Activités M.C.C.
Formalisme
Traitements M.C.T.,
M.O.T.,
M.P.T.
Dynamique
Oui
Outils associés
Non X
Oui
Standard
Non X
Faible X
Flexibilité Moyenne
Forte
Coût d'acquisition
Faible
Complexité d'utilisation Moyenne X
Forte
Nature de l'environnement Structuré X
Semi-structure
Non structuré
Stable X

41 de 273
 Dimension Critères
Instable
Certain X
Incertain
M.C.C. : Modèle Conceptuel des Communications;
M.C.D. : Modèle Conceptuel des Données;
M.O.T. : Modèle Organisationnel des Traitements;
M.O.D. : Modèle Organisationnel des Données;
M.L.D. : Modèle Logique des Données;
M.P.T. : Modèle Physique des Traitements.

Tableau 3 Analyse de la méthode MERISE

3.4.2. La méthode OMT

Le Tableau 4 montre les différents aspects pris en compte par la méthode OMT.
Pour OMT, les données ont bien sûr une très grande importance et le formalisme des
données est très complet (il permet en particulier de représenter l'héritage, l'agrégation
et les contraintes). Au niveau des formalismes, OMT est intéressante car elle n'en utilise
que trois (le modèle Objet, le Diagramme d'état et le Diagramme des Flots de Données)
pour le cycle de vie du projet qui se déroule en quatre phases : l'analyse, la conception
du système, la conception des données et l'implémentation. Cependant, on ne retrouve
pas de modèle suggérant un rapprochement entre concepteurs et utilisateurs (comme
par exemple le modèle Organisationnel des Traitements de la méthode MERISE), pour
la prise en compte des besoins des utilisateurs.
Le système étudié (le terme 'organisation' n'apparaît pas vraiment dans OMT, ce qui
constitue à notre sens une limitation) est connu par ses échanges et ses actions, mais
par sa conception objet. OMT peut s'appliquer à des systèmes semi-structures et
instables dans une mesure prévisible. Par principe, l'approche objet permet d'obtenir
toutes les informations nécessaires sur les données.
OMT couvre presque entièrement le cycle de vie du projet. Le cycle de développement
utilisé est le cycle en spirale (privilégié pour le prototypage), mais celui-ci est
uniquement centré sur la modélisation de l'application, et son raffinement successif. Son
approche est également descendante, l'utilisateur n'est impliqué qu'au tout début du
projet, dans la phase d'analyse. On trouve dans la plupart des méthodes orientées
objets de telles limitations : l'utilisateur y est quasi inexistant.

42 de 273
 Dimension Critères
Cascade
Cycle de développement Spirale X
Y
Incrémental
Analyse X
Modélisation X
Phases concernées
Conception X
Validation technique X
Descendante X
Approche Ascendante
Evolutive
Pas
Peu X
Degré d'implication de l'utilisateur Moyen
Beaucoup
Essentiel
Début X
Moment d'implication de l'utilisateur Milieu
Fin
Interprétée X
Position de l'analyse
Directe
Données 1
Principe de construction Activités 3
(ordre d'apparition des formalismes) Traitements
Dynamique 2
Niveaux d'abstraction X
Généralisation / X
Principe d'assemblage Spécification
Type / Occurrence X
Stratégique / Tactique
Données M.O
Activités D.F.D
Formalisme Traitements
Dynamique Diag. Evts,
D.E. évolué
Oui
Outils associés
Non X
Oui
Standard
Non X
Faible
Flexibilité Moyenne X
Forte
Coût d'acquisition
Complexité d'utilisation Faible
Moyenne X
43 de 273
 Dimension Critères
Forte
Structuré X
Semi-structure X
Non structuré
Nature de l'environnement Stable X
Instable X
Certain X
Incertain
M.O. : Modèle Objet; D.F.D. .Diagramme de Flux de Données;
Diag. Evs : Diagramme d'événements; D.E. évolué : Diagramme d'état
évolué
Tableau 4 Analyse de la méthode OMT

3.4.3. UML

UML est défini comme un langage d'unification des différentes méthodes objet. Ce n'est
pas une méthode, c'est pourquoi cette analyse ne s'intéresse qu'à la dimension
représentation (Tableau 5). On pourra éventuellement se reporter à la méthode OMT
pour les autres aspects méthodologiques ou au mieux au RUP (Rational Unified
Process).
UML provient d'une fusion des principales modélisations objets. En cela, il reprend et
améliore leurs formalismes. Pour ce qui est des données, UML simplifie l'écriture du
modèle de données d'OMT. Mais UML utilise deux fois plus de modèles qu'OMT, ce qui
peut être déroutant, même si ces modèles sont basés sur des formalismes similaires
(comme les diagrammes de classe et les diagrammes d'objets par exemple). Les
diagrammes utilisés sont : le diagramme de classe, le diagramme d'objet, le diagramme
de collaboration, les cas d'utilisation, les diagrammes de séquences, le diagramme
d'activité et les diagrammes d'état.
L'emploi des cas d'utilisation de Jacobson incite à intégrer ou tout au moins à prendre
en compte les besoins de l'utilisateur, ce qui constitue un progrès très important par
rapport à OMT en particulier.

Dimension Critères
Cascade
Cycle de développement Spirale
Y
Incrémental

44 de 273
 Dimension Critères
Analyse
Modélisation
Phases concernées
Conception
Validation technique
Descendante
Approche Ascendante
Evolutive
Pas
Peu
Degré d'implication de l'utilisateur Moyen
Beaucoup
Essentiel
Début
Moment d'implication de l'utilisateur Milieu
Fin
Position de l'analyse
Interprétée X
Directe
Données 1,3
Principe de construction Activités 2,4
(ordre d'apparition des formalismes) Traitements 6
Dynamique 5
Niveaux d'abstraction X
Généralisation / X
Principe d'assemblage Spécification
Type / Occurrence X
Stratégique / Tactique
Données DC, DO,
Dcol
Formalisme Activités CU, Dseq.
Traitements DA
Dynamique D.E.
Oui X
Outils associés
Non
Oui X
Standard
Non
Faible
Flexibilité Moyenne X
Forte
Coût d'acquisition
Faible
Complexité d'utilisation Moyenne X
Forte
Nature de l'environnement Structuré X
Semi-structure X
Non structuré X
Stable X

45 de 273
 Dimension Critères
Instable X
Certain X
Incertain
DC : Diagramme de Classe;
DO : Diagramme d'Objet;
Dcol : Diagramme de Collaboration;
CU : Cas d'Utilisation;
DSeq : Diagramme de Séquence;
DA : Diagramme d'Activités;
DE : Diagramme d'État.
Tableau 5 Analyse de la méthode UML
(pour les autres dimensions, cf. Tableau 4)

3.4.4. La méthode SADT

Le Tableau 6 montre les différents aspects pris en compte par la méthode SADT.
Dimension Critères
Cascade X
Cycle de développement Spirale
Y
Incrémental
Analyse X
Modélisation X
Phases concernées
Conception X
Validation technique
Descendante X
Approche Ascendante
Evolutive
Pas
Peu
Degré d'implication de l'utilisateur Moyen X
Beaucoup
Essentiel
Début X
Moment d'implication de l'utilisateur Milieu X
Fin
Interprétée
Position de l'analyse
Directe X
Données 1
Principe de construction Activités 1
(ordre d'apparition des formalismes) Traitements
Dynamique
Principe d'assemblage Niveaux d'abstraction

46 de 273
 Dimension Critères
Généralisation / X
Spécification
Type / Occurrence
Stratégique / Tactique
Données Datagramme
Activités Actigramme
Formalisme
Traitements
Dynamique
Oui
Outils associés
Non X
Oui
Standard
Non X
Faible X
Flexibilité Moyenne
Forte
Coût d'acquisition
Faible X
Complexité d'utilisation Moyenne
Forte
Structuré X
Semi-structure
Non structuré
Nature de l'environnement Stable X
Instable
Certain X
Incertain
Tableau 6 Analyse de la méthode SADT

SADT permet l'analyse et la modélisation de systèmes à l'aide de deux formalismes : les

datagrammes et les actigrammes. Cette méthode est très utilisée pour décrire de façon
structurée des problèmes et leurs solutions. Elle comprend plusieurs concepts dont celui
de dualité activités-données. Ce qui entraîne un test de correspondance entre les deux
modèles par une analyse de liens Activités/Données et de liens Données/Activités. Elle
procède par une démarche descendante (Top-Down) de généralisation/spécification.
Notons que les formalismes de la méthode SADT ont été exploités par Benaissa [61] et
Abed et Angue [62] pour la modélisation statique des tâches et/ou des activités
humaines et complémentée par les réseaux de Pétri pour la composante dynamique de
ces tâches et activités.
La méthode s'applique à l'analyse fonctionnelle de systèmes. De par son analyse
descendante, hiérarchique et structurée, elle ne peut s'appliquer qu'à des

47 de 273
 environnements stables, certains et structurés. Seul l'aspect qualitatif des données est
pris en compte. Un aspect important de la méthode est qu'elle suggère une analyse
prenant en compte le point de vue des intervenants humains.
SADT facilite surtout l'analyse et la modélisation du système (même si ses auteurs
suggèrent d'aller jusqu'à sa validation) et suit le cycle en cascade. Son approche est
bien sûr descendante, et l'utilisateur est surtout impliqué lors de cette phase d'analyse.

3.4.5. La méthode OSSAD

Le Tableau 7 montre les différents aspects pris en compte par la méthode OSSAD.
OSSAD se compose de trois modèles : le modèle Abstrait qui comprend 2 graphes (A1 :
relations entre fonctions ou activités, A2 : matrice Activité/Rôle), le modèle descriptif qui
comprend 5 graphes (D1 : relations entre rôles, D2 : relations entre tâches, D3 :
diagramme d'une tâche (1 rôle), D4 : diagramme d'une procédure (plusieurs rôles), D5 :
description détaillée d'une opération). Cette méthode ne possède pas véritablement de
modèle de données mais propose un concept de fiches descriptives permettant de
recenser les ressources, activités, tâches et acteurs du système étudié, en y incluant les
relations d'appartenance ou de subordination. En principe, les méthodes de
représentation disponibles dans cette méthode sont centrées sur l'analyse du travail
humain.
Son modèle abstrait (représentant ce qui doit être fait et pourquoi) nécessite un système
stable et certain. Son modèle descriptif (représentant qui fait quoi et comment) n'utilise
pas une représentation formelle. La méthode peut donc s'appliquer à un environnement
semi-structure. Au travers de ses diagrammes, elle fournit des informations relatives à la
pertinence et la qualité des données.
OSSAD a pour but la réorganisation et sa simulation. Elle s'intéresse à l'analyse et à la
spécification et laisse le choix d'utiliser d'autres méthodes (MERISE, SADT par
exemple) pour ce qui est de l'implémentation. Elle utilise le cycle de vie en V et suit une
démarche descendante.
OSSAD est très intéressante pour la modélisation de la coopération. Elle permet,
comme la majorité des méthodes, de représenter les flux de données d'une
organisation, mais elle permet aussi de représenter la coordination (ou synchronisation)
au sein de l'organisation, à l'aide du modèle des traitements. La représentation la plus
48 de 273
synthétique proposée par OSSAD consiste en une matrice (ou tableau), dont les lignes
désignent des activités de l'entreprise et dont les colonnes correspondent à des rôles,
c'est-à-dire à un ensemble de responsabilités. Une case cochée de cette matrice
indique la participation du rôle à l'activité. Elle symbolise une tâche.

Dimension Critères
Cascade
Cycle de développement Spirale
Y X
Incrémental
Phases concernées Analyse X
Modélisation X
Conception X
Validation technique
Approche Descendante X
Ascendante
Evolutive
Degré d'implication de l'utilisateur Pas
Peu
Moyen
Beaucoup
Essentiel X
Moment d'implication de l'utilisateur Début X
Milieu X
Fin
Position de l'analyse Interprétée
Directe X
Données 3
Principe de construction Activités 1
(ordre d'apparition des formalismes) Traitements 2
Dynamique
Principe d'assemblage Niveaux d'abstraction X
Généralisation / X
Spécification
Type / Occurrence
Stratégique / Tactique
Formalisme Données Fiches OSSAD
Activités Diag. A1, A2,
D1,D2
Traitements Diag. D3, D4, D5
Dynamique
Outils associés Oui X
Non
Standard Oui
Non X

49 de 273
 Dimension Critères
Flexibilité Faible
Moyenne X
Forte
Coût d'acquisition
Complexité d'utilisation Faible
Moyenne X
Forte
Nature de l'environnement Structuré X
Semi-structure X
Non structuré
Stable X
Instable
Certain X
Incertain
Fiches : Les fiches permettent de décrire les ressources, les rôles, les acteurs,
les unités, les tâches, les opérations, les procédures et les outils.
A1 : relations (de données) entre fonctions et sous-fonctions.;
A2 : Matrice Activité / Rôle.
D1 : Relations (de données) entre Rôles.
D2 : Relations (de données) entre rôles et tâches.
D3 : Diagramme d'une tâche (liée à 1 rôle).
D4 : Diagramme d'une procédure incluant plusieurs rôles.
D5 : Détail d'une opération ou d'une tâche (basé sur les actigrammes).
Tableau 7 Analyse de la méthode OSSAD

3,4.6. UP (Unified Process)

Le Tableau 8 montre les différents aspects pris en compte par la méthode UP.
Le Processus Unifié (UP) [48] est un processus de développement logiciel « itératif et
incrémental, centré sur l'architecture, conduit par les cas d'utilisation et piloté par les
risques » :
• Itératif et incrémental : le projet est découpé en itérations de courte durée (environ 1
mois) qui permettent de mieux suivre l'avancement global. A la fin de chaque itération,
une partie exécutable du système final est produite, de façon incrémentale.
• Centré sur l'architecture : tout système complexe doit être décomposé en parties
modulaires afin de garantir une maintenance et une évolution facilitées. Cette
architecture (fonctionnelle, logique, matérielle, etc.) doit être modélisée en UML et pas
seulement documentée en texte.

50 de 273
 Piloté par les risques : les risques majeurs du projet doivent être identifiés au plus tôt
mais surtout levés le plus rapidement possible. Les mesures à prendre dans ce cadre
déterminent l'ordre des itérations.
Conduit par les cas d'utilisation : le projet est mené en tenant compte des besoins
et des exigences des utilisateurs. Les cas d'utilisation du futur système sont identifiés,
décrits avec précision et priorisés.
La gestion d'un tel processus est organisée suivant les quatre phases suivantes :
initialisation, élaboration, construction et transition.
La phase d'initialisation conduit à définir la « vision » du projet, sa portée, sa faisabilité,
son « business case », afin de pouvoir décider au mieux de sa poursuite ou de son
arrêt.
La phase d'élaboration poursuit trois objectifs principaux en parallèle :
Identifier et décrire la majeure partie des besoins utilisateurs;
Construire (et pas seulement décrire dans un document) l'architecture de base du
système;
Identifier les risques majeurs du projet.
La phase de construction consiste surtout à concevoir et implémenter l'ensemble des
éléments opérationnels (autres que ceux de l'architecture de base). C'est la phase la
plus consommatrice en ressources et en efforts.
Enfin, la phase de transition permet de faire passer l'application des développeurs aux
utilisateurs finaux. Les mots-clés sont : conversion des données, formation utilisateurs,
déploiement, béta-tests.

51 de 273
 Phases
ïnceptîon Elaboration

Business Modelïng
Requirements
Analysis & Design

Implementation
Test
Deployment
Configuration
& Change Mgmt
Project Management
Environment

Figure 7 Processus UP [48]

Chaque phase est elle-même décomposée séquentiellement en itérations limitées dans

le temps (entre 2 et 4 semaines). Le résultat de chacune d'elles est un système testé,
intégré et exécutable. L'approche itérative est fondée sur la croissance et raffinement
successif d'un système par le biais d'itérations multiples. Retours en arrières (Feed-
back) et adaptation cycliques sont les moteurs principaux permettant de converger vers
un système satisfaisant. Le système croît avec le temps de façon incrémentale, itération
par itération, et c'est pourquoi cette méthode porte également le nom de développement
itératif et incrémental. Il s'agit là du principe le plus important du Processus Unifié.
Les activités de développement sont définies selon cinq axes fondamentaux qui
décrivent la capture des exigences, l'analyse et la conception, l'implémentation, le test
et le déploiement. La modélisation métier est un axe amont optionnel et transverse aux
projets. Enfin, trois axes appelés de support complètent le tableau : gestion de projet,
gestion du changement et de la configuration, ainsi que la mise à disposition d'un
environnement complet de développement incluant aussi bien des outils informatiques
que des documents et des guides méthodologiques.
Contrairement au processus en cascade (souvent appelé cycle en V en France), le
Processus Unifié ne considère pas que les activités de développement sont purement

52 de 273
séquentielles. En fait, une itération comporte une certaine quantité de travail dans la
plupart des activités. Mais la répartition de l'effort relatif entre celles-ci change avec le
temps. Les premières itérations ont tendance à mettre plus l'accent sur les exigences et
la conception, les autres moins, à mesure que les besoins et l'architecture se stabilisent
grâce au processus de feed-back et d'adaptation.
UP doit donc être compris comme une trame commune des meilleures pratiques de
développement, et non comme l'ultime tentative d'élaborer un processus universel.
Dimension Critères
Cascade
Cycle de développement Spirale
Y
Incrémental X
Analyse X
Modélisation X
Phases concernées
Conception X
Validation technique X
Descendante
Approche Ascendante
Évolutive X
Pas
Peu
Degré d'implication de l'utilisateur Moyen
Beaucoup X
Essentiel
Début X
Moment d'implication de l'utilisateur Milieu X
Fin
Interprétée X
Position de l'analyse
Directe
Données 1,3
Principe de construction Activités 2,4
(ordre d'apparition des formalismes) Traitements 6
Dynamique 5
Niveaux d'abstraction X
Généralisation / X
Principe d'assemblage Spécification
Type / Occurrence X
Stratégique / Tactique
Données DC, DO, Dcol
Activités CU, Dseq.
Formalisme
Traitements DA
Dynamique D.E.
Oui X
Outils associés
Non

53 de 273
 Dimension Critères
Oui X
Standard
Non
Faible
Flexibilité Moyenne X
Forte
Coût d'acquisition
Faible
Complexité d'utilisation Moyenne
Forte X
Structuré X
Semi-structure X
Non structuré X
Nature de l'environnement Stable X
Instable X
Certain X
Incertain
DC : Diagramme de Classe;
DO : Diagramme d'Objet;
Dcol : Diagramme de Collaboration;
CU : Cas d'Utilisation;
DSeq : Diagramme de Séquence;
DA : Diagramme d'Activités;
DE : Diagramme d'État.
Tableau 8 Analyse de la méthode UP

54 de 273
3.4.7. Processus 2TUP (2 Tracks Unified Process)

Le processus 2TUP de Valtech [49] est un processus UP (cf. 3.4.6) mais il apporte en
plus une réponse aux contraintes de changement continuel imposées aux systèmes
d'information de l'entreprise. L'idée fondatrice de 2TUP a été le constat que toute
évolution imposée au système d'information peut se décomposer et se traiter
parallèlement, suivant un axe fonctionnel et un axe technique. A l'issue des évolutions
du modèle fonctionnel et de l'architecture technique, la réalisation du système consiste
à fusionner les résultats de ces deux branches du processus. La fusion des deux
branches conduit à l'obtention d'un processus de développement en forme de Y comme
illustré dans la Figure 8, ci-après.

Étude préliminaire

Capture des besoins Capture des besoins

fonctionnels techniques

Conception
eénériaue

Conception préliminaire

| Conception détaillée Prototype

Codage et tests

Figure 8 Processus de développement en Y (adaptée de [49])

55 de 273
Branche fonctionnelle (gauche):
• Capture les besoins fonctionnels et produit un modèle des besoins focalisé sur le
métier des utilisateurs;
• Permet de qualifier, au plus tôt, le risque de produire un système inadapté aux
utilisateurs;
• Permet de produire une spécification fonctionnelle qui ne dépendra d'aucune
technologie particulière.

Branche architecture technique (droite) :

• Permet de définir la liste des contraintes dimensionnant la conception du système
(capture des besoins techniques) : Outils, matériels, pré-requis d'architecture
technique, etc.
• Produit une conception générique ayant comme objectif d'uniformiser et de réutiliser
les mêmes mécanismes pour tout le système.
• Propose de construire un prototype valide qui ne dépendra pas de la spécification
fonctionnelle. Dans cette optique, la technologie informatique devient elle-même un
sujet de modélisation et de conception afin de bénéficier de la réutilisation, de
l'extensibilité et de la faisabilité technique (prototypage de la réalisation technique).

Branche conception (milieu) :

• Élaboration de la conception préliminaire qui intègre le modèle d'analyse
fonctionnelle dans l'architecture technique de manière à organiser la structure
générale des composants du système à développer.
• La conception détaillée, qui étudie ensuite comment réaliser chaque composant.
• L'étape de codage, qui produit les composants et teste au fur et à mesure les
unités de code réalisées.
• L'étape de recette, qui consiste enfin à valider les fonctionnalités du système.

Selon Pascal Roques et Frank Vallée [49], les cas d'utilisation sont les outils utilisés
pour définir les besoins fonctionnels et techniques. Pour la capture des besoins
fonctionnels, les cas d'utilisation portent uniquement sur la plus-value métier des
fonctions du système. Chaque cas d'utilisation met en évidence des classes d'analyse
qui sont les concepts utilisés par l'utilisateur et des scénarios qui établissent les
56 de 273
 comportements attendus du système. Pour la capture des besoins techniques, la nature
des cas d'utilisation est adaptée en fonction des plus-values opérationnelles du système
pour ses exploitants. Chaque cas d'utilisation technique structure des spécifications
d'architecture que l'on peut par la suite décomposer en couches logicielles. Les cas
d'utilisation techniques permettent de concevoir les classes qui vont offrir une réponse
aux contraintes opérationnelles du système.

Les auteurs Pascal Roques et Frank Vallée [49] précisent que quoique les concepts
présentés dans la démarche en Y ne sont pas spécifiquement liés à une notation
particulière, il est difficile d'envisager le processus 2TUP sans recourir à UML comme
support de modélisation. Nous ne détaillerons par les concepts UML dans ce mémoire
compte tenu de la richesse de la littérature traitant d'UML. La démarche de modélisation
préconisée par [49] se compose des étapes suivantes (nous nous limitons à la branche
gauche du processus en Y en raison des objectifs du présent mémoire):

Capture initiale des besoins : Étude préliminaire

• Recueil des besoins : Permet d'effectuer un premier repérage des besoins

fonctionnels et opérationnels, en utilisant principalement le texte ou des diagrammes
très simples. Il prépare les activités plus formelles de capture des besoins
fonctionnels et techniques. Il aboutit à la définition de la problématique et des
attentes dans un recueil portant le nom de « cahier de charge ».

• Modélisation du contexte

o Identification des acteurs;

o Identification des messages acteurs/système;
o Élaboration des diagrammes de contexte (type de diagramme UML :
Collaboration).

La démarche mise en œuvre dans cette étape est synthétisée par la figure suivante:

57 de 273
 Figure 9 Démarche de capture initiale des besoins ([49])

a. Capture des besoins fonctionnels

a.1. Diagrammes de Cas d'utilisation

La technique recommandée pour identifier les cas d'utilisation à partir du modèle de

contexte est de considérer l'intention fonctionnelle de l'acteur par rapport au système dans
le cadre de l'émission et de la réception de chaque message acteur/système. En
regroupant les intentions fonctionnelles en unités cohérentes, on obtient les cas
d'utilisation recherchés, c'est à dire ce que les acteurs veulent faire avec le système?

a.2. Identification des classes candidates

Le but est de préparer la modélisation orientée-objet en aidant à trouver les classes

candidates du futur modèle statique d'analyse et définir leur responsabilité à l'intérieur du
système. On établit ainsi le diagramme des classes candidates.

a.3. Valider et consolider

Pour s'assurer que l'analyse fonctionnelle préliminaire couvre bien l'ensemble des besoins,
on doit se poser les questions suivantes :

Les frontières du système sont-elles bien définies?

58 de 273
 • Les acteurs sont-ils tous pris en compte?
• Chaque cas d'utilisation est-il déclenché par un acteur?
• Le niveau d'abstraction des cas d'utilisation est-il homogène?
• Toutes les fonctionnalités du système sont-elles traitées?

La démarche mise en œuvre dans cette étape est synthétisée par la figure suivante:

Capture des besoins fonctionnels

Figure 10 Démarche de capture des besoins fonctionnels ([49])

b. Analyse

• Répartition des classes candidates en catégories. Une catégorie consiste en un

regroupement logique de classes à forte cohérence interne et faible couplage
externe.
• Élaboration du modèle statique : Les diagrammes de classes préliminaires obtenus
lors du découpage en catégories sont détaillés, complétés et optimisés (introduisant
des super-classes par généralisation).
• Élaboration du modèle dynamique : Diagrammes de collaboration, de séquence et
d'état.

59 de 273
La démarche mise en œuvre dans cette étape est synthétisée par la figure suivante:

Fiches de
description de
cas d'utilSsatior
f.Affiner les
classes

2.Affiner les
associations

3. Ajouter les
attributs

4. Ajouter les
opérations Diagramme de
classes optimisé 1
5. Optimiser avec
i la généralisation

Diagramme de classes complété

Figure 11 Démarche de l'étape d'analyse ([49])

2TUP (comme UP) doit donc être compris comme une trame commune des meilleures
pratiques de développement, et non comme l'ultime tentative d'élaborer un processus
universel.
Le Tableau 9 montre les différents aspects pris en compte par le processus 2TUP.

Dimension Critères
Cascade
Cycle de développement Spirale
Y X
Incrémental X
Analyse X
Modélisation X
Phases concernées
Conception X
Validation technique X

60 de 273
 Dimension Critères
Descendante
Approche Ascendante
Évolutive X
Pas
Peu
Degré d'implication de l'utilisateur Moyen
Beaucoup X
Essentiel
Début X
Moment d'implication de l'utilisateur Milieu X
Fin
Position de l'analyse
Interprétée X
Directe
Données 1,3
Principe de construction Activités 2,4
(ordre d'apparition des formalismes) Traitements 6
Dynamique 5
Niveaux d'abstraction X
Généralisation /
X
Principe d'assemblage Spécification
Type / Occurrence X
Stratégique / Tactique
Données DC, DO,
Dcol
Formalisme Activités CU, Dseq.
Traitements DA
Dynamique DC, D.E.
Oui X
Outils associés
Non
Oui
Standard
Non X
Faible
Flexibilité Moyenne X
Forte
Coût d'acquisition
Faible
Complexité d'utilisation Moyenne
Forte X
Structuré X
Semi-structure X
Non structuré X
Nature de l'environnement Stable X
Instable X
Certain X
Incertain

61 de 273
 Dimension I Critères
DC : Diagramme de Classe;
DO : Diagramme d'Objet;
Dcol : Diagramme de Collaboration;
CU : Cas d'Utilisation;
DSeq : Diagramme de Séquence;
DA : Diagramme d'Activités;
DE : Diagramme d'État.
Tableau 9 Analyse du processus 2TUP

3.4.8. Méthode Gestion des Parcours (GPS)

Élaborée en 2001 par la CSST (Commission de la santé et de la sécurité du travail du

Québec) la méthode Gestion des Parcours (GPS) [50] a pour objectif principal de fournir
aux utilisateurs et aux développeurs un cadre de développement unique pour tous les
projets de la CSST et dans lequel les activités à réaliser (appelées parcours) et les
biens livrables sont clairement définis et limités en nombre. Les raisons principales de
cette limitation sont, d'une part de concentrer les efforts sur les activités couramment
menées lors de développement de logiciels, évitant ainsi de se perdre à travers les
méandres théoriques des méthodes offertes sur le marché et d'autre part, de rendre la
méthode GPS facile à utiliser, c'est à dire ne nécessitant pas des efforts prolongés pour
être assimilée et mise en œuvre.
Orientée Atelier de génie logiciel (AGL) et basée sur les concepts d'UML, notamment
les cas d'utilisation, les diagrammes d'activités, les diagrammes de classes et les
services de composants (packages), la méthode GPS est décomposée selon les
parcours suivants :
• Parcours général de développement;
• Parcours Web informationnel;
• Parcours Entretien mineur Web informationnel;
• Parcours de développement Web transactionnel;
• Implémentation d'une solution logicielle commerciale;
• Parcours de production de composants communs;
• Parcours de développement informationnel;
• Réparation - Migration à Windows.

62 de 273
 Compte tenu du contexte de ce mémoire, nous nous limitons à décrire le parcours
général de développement.

3.4.8.1. Parcours général de développement

Le parcours général de développement est le parcours le plus complet. Il couvre

l'ensemble des tâches de développement logiciel, de l'identification des services à offrir à
la mise en place de la solution conçue.
Les activités suivantes constituent le parcours général de développement :
• Définir les éléments architecturaux de la solution;
• Analyser la solution informatique;
• Construire la solution informatique;
• Implanter et déployer la solution informatique.

La Figure 7 résume le processus global du parcours général de développement de la

méthode GPS.

î
Définir les éléments
architecturaux de la solution
Y
Analyser la solution
informatique

Construire la solution
informatique

Implanter et déployer
la solution informatique

Figure 12 Activités du parcours général de développement [50]

63 de 273
3.4.8.2. Activité : Définir les éléments architecturaux de la solution

Cette activité inclut les tâches suivantes :

• Identifier les besoins;
• Décrire le modèle de données;
• Identifier l'architecture des services;
• Spécifier les règles d'interaction avec l'application;
• Décrire les règles physiques de l'application;
• Détailler l'infrastructure technologique de l'application;
• Établir la stratégie de conversion des données.

La Figure 13 représente les tâches de l'activité et leurs dépendances. Dans cette figure,
et toutes celles qui suivront, les lignes pointillées indiquent des itérations inter-tâches;
tandis que les lignes horizontales (en gras) représentent une synchronisation entre
plusieurs tâches (ou activités) avant de débuter la tâche suivante.

Figure 13 Tâches de l'activité Définir les éléments architecturaux de la solution [50]

64 de 273
3.4.8.3. Activité : Analyser la solution informatique

Cette activité inclut les tâches suivantes :

• Décrire en détail le comportement attendu de l'application;
• Ordonnancer les cas d'utilisation en différé;
• Définir l'interface utilisateur de l'application;
• Définir la navigation;
• Compléter le modèle de données;
• Réviser l'architecture des services;
• Identifier l'architecture de composants physiques de l'application;
• Définir les opérations des composants;
• Détailler le modèle physique de données;
• Identifier les éléments critiques et/ou à risque de l'application;
• Élaborer la stratégie de réalisation des essais;
• Concevoir les essais fonctionnels;
• Concevoir les essais intégrés (comportement avec d'autres systèmes);
• Concevoir les essais de performance.

La Figure 14 représente les tâches de l'activité et leurs dépendances.

65 de 273
 Figure 14 Tâches de l'activité Analyser la solution informatique [50]

3.4.8.4. Activité : Construire la solution informatique

Alors que les deux activités précédentes visent l'élaboration de la solution en termes
d'analyse et de conception, cette activité a pour but de concrétiser cette solution en
procédant à sa réalisation comme telle. Il s'agit donc ici de spécifier le fonctionnement
interne des composants physiques identifiés précédemment, de définir où ils seront
déployés sur le plan technologique, de les programmer et de s'assurer de leur validité,
tant sur le plan des services utilisateurs qu'ils rendent que sur le plan technique. Cette
activité est composée des tâches suivantes :

• Identifier les composants de déploiement;

• Produire la présentation graphique d'un composant;
• Produire la structure physique des données;
• Concevoir les essais unitaires;
• Définir le fonctionnement interne des composants;

66 de 273
• Programmer les opérations d'un composant;
• Réaliser les essais unitaires;
• Préparer l'environnement des essais fonctionnels;
• Réaliser les essais fonctionnels;
• Préparer l'environnement des essais intégrés;
• Réaliser les essais intégrés;
• Préparer l'environnement des essais de performance;
• Supporter la réalisation des essais de performance.

La Figure 15, ci-après, représente les tâches de l'activité et leurs dépendances.

Figure 15 Tâches de l'activité Construire la solution informatique [50]

67 de 273
3.4.8.5. Activité : Implanter et déployer la solution informatique

La présente activité a pour but de rendre l'application, construite au cours de l'activité

précédente, disponible aux utilisateurs. Une série d'essais visant à s'assurer
officiellement de la conformité de l'application sont réalisés en mode similaire à une
exploitation normale de l'application. Une fois ces tâches réalisées avec succès, on peut
alors procéder à la mise en production de l'application et à la préparation de son
entretien et de son évolution.
Cette activité inclut les tâches suivantes schématisées dans la Figure 16:

• Préparer l'environnement des essais d'acceptation;

• Supporter la réalisation des essais d'acceptation;
• Produire un plan de mise en production de l'application;
• Préparer l'environnement des essais d'acceptation intégrés;
• Supporter la réalisation des essais d'acceptation intégrés;
• Préparer l'environnement des essais EAR (Essais Après Réalisation);
• Supporter la réalisation des essais EAR;
• Préparer l'environnement de formation;
• Supporter la diffusion de la formation;
• Préparer l'environnement des essais de pré-production;
• Supporter la réalisation des essais de pré-production;
• Préparer l'entretien et l'évolution;
• Supporter le personnel des services de mise en production et d'assistance post-
implantation.

68 de 273
 Figure 16 Tâches de l'activité Impianteret déployer la solution informatique [50]

En règle générale, chacun des parcours définis par la méthode GPS est décomposé en
activités qui sont décomposées en tâches. Et pour guider les différents intervenants
dans la réalisation des tâches qui leur incombent, chaque tâche est décrite dans une
fiche où sont précisés les objectifs, les conditions préalables, la description de la tâche,
les intervenants, les résultats attendus et les guides à utiliser pour accomplir la tâche.
L'ensemble de la documentation de la méthode GPS est accessible via l'Intranet de la
CSST et comporte des hyperliens facilitant la navigation à travers les parcours, les
activités, les tâches et les guides.
Selon Mme Annie Gilbert, Responsable du soutien méthodologique à la CSST, l'une
des forces de la méthode GPS est son découpage en parcours répondant chacun à un

69 de 273
type de développement spécifique (Développement de nouveau produit, acquisition de
progiciel, développement Web, production de composants communs, etc.). Ce
découpage permet de délimiter le domaine, de savoir exactement quoi faire au lieu
d'adapter à chaque fois la méthode aux besoins et enfin de profiter du retour
d'expérience généré par les développements antérieurs réalisés dans le contexte d'un
même parcours.

Le Tableau 10, renseigné en concertation avec Mme Annie Gilbert, résume les
différents aspects pris en compte par la méthode GPS.
Dimension Critères
Cascade X
Cycle de développement Spirale
Y
Incrémental X
Analyse X
Modélisation X
Phases concernées
Conception X
Validation technique
Descendante X
Approche Ascendante
Evolutive
Pas
Peu
Degré d'implication de l'utilisateur Moyen
Beaucoup X
Essentiel X
Début X
Moment d'implication de l'utilisateur Milieu X
Fin X
Interprétée X
Position de l'analyse
Directe
Données 2,4
Principe de construction Activités 1,3
(ordre d'apparition des formalismes) Traitements 6
Dynamique 5
Niveaux d'abstraction X
Généralisation /
X
Principe d'assemblage Spécification
Type / Occurrence X
Stratégique / Tactique

70 de 273
 Dimension Critères
Données DC
Activités CU
Formalisme
Traitements DA
Dynamique DC
Oui X
Outils associés
Non
Oui
Standard
Non X
Faible
Flexibilité Moyenne X
Forte
Coût d'acquisition
Faible X
Complexité d'utilisation Moyenne
Forte
Structuré X
Semi-structure X
Non structuré
Nature de l'environnement Stable X
Instable X
Certain X
Incertain
DC : Diagramme de Classe;
DO : Diagramme d'Objet;
Dcol : Diagramme de Collaboration;
CU : Cas d'Utilisation;
DSeq : Diagramme de Séquence;
DA : Diagramme d'Activités;
DE : Diagramme d'État.
Tableau 10 Analyse de la méthode GPS

71 de 273
3.5. Outils de modélisation

Si le besoin de s'appuyer sur une méthode appropriée pour modéliser les processus
métier est évident, il n'en demeure pas moins que le besoin d'outils supportant la
méthode et facilitant la gestion de toute l'information générée est aussi fondamental.
L'objectif de cette section est de présenter quelques outils de modélisation de
processus (process modelling). Il s'agit là de solutions permettant la modélisation de
processus mais n'allant pas jusqu'à l'informatisation (la génération de codes ou
l'exécution) du processus lui-même (Ce volet étant hors du cadre du présent mémoire).
Ces outils permettent de modéliser les processus, de générer la documentation
décrivant les modèles et de mettre cette description à disposition des utilisateurs, en
général via l'Internet et/ou l'Intranet. Un facteur de succès important, car l'ensemble des
informations ainsi publiées contribue à la communication entre les différents acteurs, à
l'enrichissement et l'amélioration des modèles par la confrontation de divers points de
vue, par l'identification d'éventuelles incohérences ou redondances et par la mise en
place d'un référentiel unique. Ce référentiel unique contribue certainement à une
meilleure gestion des connaissances de l'entreprise.

Selon http://www.accedeconseil.fr/CONCEPTS.htm, on peut classer les outils

disponibles en 3 catégories :
• Les outils de représentation graphique : ces outils basiques se contentent de la
représentation visuelle et servent généralement en complément tels qu'un traitement
de texte.
• Les outils qui complètent l'aspect visuel par une information descriptive non
structurée : les outils de cette catégorie permettent d'attacher aux modèles des
documents tels que procédures, règlements, directives, etc.
• Les outils de modélisation proprement dits complètent la représentation visuelle par
une base de données structurée (référentiel partagé) et sont généralement
complétés par des fonctions de suivi des coûts (costing).

Selon Emmanuel Ménager, responsable de l'offre ARIS chez l'américain IDS Scheer, Le
BPM (Business Process Modelling) recouvre deux catégories d'outils complémentaires.

72 de 273
D'une part ceux qui permettent de modéliser les processus existants et futurs, puis de
mettre cette description à disposition des utilisateurs, via l'intranet. D'autre part ceux qui
les automatisent - on parle d'exécution des processus - au travers de nouvelles
applications informatiques. Les offres concernant la première catégorie sont
architecturées autour d'un référentiel que les utilisateurs - essentiellement les
responsables opérationnels - vont constituer et alimenter, en identifiant chaque
processus et en spécifiant ses étapes, les personnes impliquées et les règles métiers
précisant les actions à entreprendre. «Ce référentiel n'est pas stable, chacun va
l'enrichir et ancrer ainsi la démarche de BPM dans la réalité de l'entreprise», précise
Emmanuel Ménager, responsable de l'offre ARIS chez IDS Scheer.

La recherche sur Internet nous a permis de constater qu'il existe plusieurs outils de ce
type ou du moins proclamant dans leur publicité être de ce type sinon plus. Ils émanent
dans la majorité d'initiatives privées. La difficulté rencontrée est de savoir quels outils
présenter dans cette section ? Sur quels critères baser notre choix ?. Ce problème se
trouve amplifié d'une part, par la publicité faite par les éditeurs sur les possibilités
« quasi exceptionnelles » de leurs outils (Marketing oblige), et d'autre part, par
l'impossibilité d'effectuer des tests réels pour affirmer ou infirmer le contenu des
catalogues publicitaires (problème de licences). Pour remédier à cette difficulté, nous
nous sommes basés sur les essais (Benchmarks) réalisés entre 2004 et 2005 par le
groupe IBS (Internet Business Services) [51] sur les outils suivants :
• ADONIS édité par BOC (Business Objectives Consulting);
• Allfusion Process Modeler édité par COMPUTER ASSOCIATES;
• ARIS Tool Set édité par IDS Scheer;
• iGrafx PROCESS édité par COREL;
• MEGA Process édité par MEGA International;
• OSS@D Process Design édité par C-LOG International;
• QUALIGRAM Manager édité par OFFICE ORGANISATION;

Les fonctionnalités testées par la firme IBS sont résumées dans le tableau suivant :

73 de 273
 Fonction Description Note
Présenter sous une forme graphique attrayante le déroulement
Représentation
d'un processus : tâche, événements, acteurs, moyens
graphique d'un /5
utilisés... Mise en évidence des liens entre processus et des
processus
échanges d'informations clés au travers de ces liens.
Production aisée, à partir des processus décrits au sein du
référentiel, de procédures aux normes ISO version 2000. Ces
Production des procédures doivent comporter une partie graphique et une
procédures et partie textuelle détaillée. Elles doivent mettre en évidence le /5
modes opératoires circuit d'approbation et le statut (approuvé, applicable,...). Les
documents produits doivent être clairs et agréables à lire afin
de faciliter leur diffusion effective.
La représentation graphique des processus s'appuie sur une
base de données de référence qui gère à la fois l'unicité des
éléments (processus, événement, acteur,... ) et la possibilité
de représenter autant que nécessaire le même élément sans
le dupliquer. À chaque élément correspond un ensemble de
propriétés qui lui est propre et doit permettre la mise en œuvre
de fonctionnalités avancées telles que le suivi des coûts
Fiche d'identité
(costing) ou la mesure de performance. Parmi les propriétés /5
processus
clés, citons : - la décomposition de coût par type (matière,
personnel, équipement, amortissement,...), - les différents
délais minimum, moyen et maximum par types (attente,
rodage, traitement), - les éléments de volumétrie. La liste de
propriétés propres à chaque type d'élément doit être
personnalisable (possibilité de rajouter des champs libres et de
renommer des champs existants).
Modélisation des échanges entre processus : définition des
Modélisation des
informations échangées (nature des données, cadre de
interfaces entre /5
l'échange) ainsi que des règles d'échange (condition,
processus
périodicité,...).
Existence dans l'outil de règles prédéfinies de validité des
graphes par rapport aux éléments qu'ils contiennent et aux
Contrôle des liens entre ces éléments. Existence de règles de syntaxe -
règles de contraignantes ou non - permettant de guider les utilisateurs. /5
représentation Possibilité de définir des règles propres à l'entreprise.
Possibilité de contrôler, pour un ensemble de graphes réalisés,
la cohérence de ces graphes par rapport aux règles édictées.
Possibilité pour le responsable de la diffusion de publier de
manière transparente (sans intervention d'un webmaster) les
processus et autres modèles au sein d'un portail accessible
sur l'intranet de l'entreprise. Cette diffusion doit inclure
Diffusion sur un l'ensemble des éléments des modèles : représentations /5
portail Intranet graphiques, compléments textuels, liens avec documents
externes. Choix des modèles et des informations à publier.
Possibilité de mise à jour incrémentale (uniquement les
données modifiées depuis la dernière mise à jour).
Contrôle de Analyse d'impact d'une modification / suppression dans un /5

74 de 273
 Fonction Description Note
l'intégrité objet. Application systématique de la modification sur
référentielle l'ensemble des éléments concernés
Intégration du
Mise en évidence au sein de la représentation graphique d'un
système
processus des moyens informatiques mis à disposition d'un
d'information dans /5
acteur ou consommés par une action : application, base de
la représentation
données, outil supportant l'information (e-mail, intranet,...).
processus
Intégration des
Mise en évidence au sein de la représentation graphique d'un
moyens
processus des moyens opérationnels mis à disposition d'un
opérationnels à la /5
acteur ou consommés par une action : moyen de production,
représentation des
de transport,...
processus
Existence de Mise à disposition de rapports standards permettant d'analyser
/5
rapports standards les données du référentiel.

Tableau 11 Fonctionnalités testées

La section suivante donne un descriptif sommaire des outils testés et des résultats des
évaluations.

3.6. Évaluation des outils testés

3.6.1. ADONIS

Descriptif

• Modélisation des processus selon une palette d'objets prédéfinie et personnalisable,

au niveau graphique comme au niveau données (attributs).
• Possibilité de définir des rapports sur les modèles, en mode tableau ou graphique et
de les exporter.
• Publication des modèles au format HTML, RTF ou XML.
• Import / Export des processus et des données au format XML ou au format de l'outil
(Adonis Définition Language).
• Fonctions de simulation.

75 de 273
 Fiche d'identité
Prix par poste de 3 à 5 K€
Prix licence Serveur de 5 à 10 K€
OS supportés Windows NT / 2000 / 9x / XP OS/2
SGBD supportés Oracle Informix MS SQL Server DB2
Tableau 12 Fiche d'identité d'ADONIS

Résultas de l'évaluation

Fonction Note
Représentation graphique d'un processus 5
Production des procédures et modes opératoires 3
Fiche d'identité processus 5
Modélisation des interfaces entre processus 4
Contrôle des règles de représentation 4
Diffusion sur un portail Intranet 2
Contrôle de l'intégrité référentielle 3
Intégration du système d'information dans la représentation
3
processus
Intégration des moyens opérationnels à la représentation processus 3
Existence de rapports standards 2
TOTAL 34
Tableau 13 Résultas de l'évaluation d'ADONIS

Points Forts
• Adaptabilité de la structure de données du référentiel.
• Simplicité de prise en main.
• Nombreux exemples fournis dans l'aide.

Points Faibles
• Ne couvre pas très bien la modélisation du niveau abstrait car il n'offre pas
suffisamment de concepts de description.
• Pas d'utilisation de stéréotypes pour étendre les concepts.

Appréciation générale
Une couverture fonctionnelle satisfaisante et un abord aisé font d'ADONIS un outil
de modélisation plutôt orienté utilisateurs.

76 de 273
3.6.2. Allfusion Process Modeler
Descriptif
• Solution de modélisation d'applications eBusiness.
• Support total de UML.
• Synchronisation de la conception et de l'application mise en œuvre.
• Portage des modèles (structurés au format XML / XSL).
• Outil de validation des normes UML.
• Génération de rapports personnalisés sur le Web.

Fiche d'identité
Prix par poste Non disponible
Prix licence Serveur Non disponible
OS supportés Win 98/2000/Me/NT 4.0
SGBD supportés Non disponible
Tableau 14 Fiche d'identité de Allfusion Process Modeler

Résultas de l'évaluation

Fonction Note
Représentation graphique d'un processus 5
Production des procédures et modes opératoires 3
Fiche d'identité processus 3
Modélisation des interfaces entre processus 3
Contrôle des règles de représentation 4
Diffusion sur un portail Intranet 4
Contrôle de l'intégrité référentielle 4
Intégration du système d'information dans la représentation
3
processus
Intégration des moyens opérationnels à la représentation processus 2
Existence de rapports standards 2
TOTAL 33
Tableau 15 Résultas de l'évaluation de Allfusion Process Modeler

Points Forts

• Les fonctions de validation des modèles notamment UML.

• L'intégration avec les modèles de données (Erwin Data Modeller) et de processus
(Process modeller).

77 de 273
 Points Faibles (selon [52])
• Absence de contrôle des accès multi-utilisateurs aux même objets.
• Absence de fonctions de recherche.
• Orienté Atelier de génie du logiciel.
• N'est pas destiné aux débutants.

Appréciation générale
Bénéficie de la longue expérience de Computer Associates en matière d'outils de
développement.

3.6.3. ARIS Tool Set

Descriptif
• ARIS Tool Set est la partie modélisation de la suite d'outils ARIS : II autorise
suivant les besoins, le descriptif et la modélisation de processus, d'organisation
de systèmes d'information ou de connaissances au sein d'un référentiel unique.
• Permet de modéliser l'ensemble des éléments d'une démarche processus :
• L'organisation de l'entreprise : processus;
• Les ressources humaines : organigramme, cartographie des connaissances;
• Les moyens techniques;
• Le système d'information (urbanisation);
• Les risques opérationnels.

Fiche d'identité
Prix par poste de 1 à 3 K€
Prix licence Serveur de 5 à 10 K€
WIN9x - WIN 2000 - WIN NT - WIN
OS supportés
XP
SGBD supportés Sybase, Oracle
Tableau 16 Fiche d'identité de ARIS Tool Set

78 de 273
Résultas de l'évaluation

Fonction Note
Représentation graphique d'un processus 5
Production des procédures et modes opératoires 5
Fiche d'identité processus 3
Modélisation des interfaces entre processus 5
Contrôle des règles de représentation 5
Diffusion sur un portail Intranet 4
Contrôle de l'intégrité référentielle 4
Intégration du système d'information dans la représentation
5
processus
Intégration des moyens opérationnels à la représentation processus 4
Existence de rapports standards 4
TOTAL 44
Tableau 17 Résultas de l'évaluation de ARIS Tool Set

Points Forts

• L'étendue de la couverture fonctionnelle.

• Le contrôle de la démarche méthodologique (respect des règles, analyse
d'impact..).
• L'accès en mode full web.

Points Faibles

• L'ergonomie est peu soignée (des améliorations sont promises avec la version 7
prévue en 2006).
• L'utilisation n'est pas facile et nécessite une bonne formation.
• Pour tirer un meilleur profit de cet outil, il faut acquérir la suite ARIS (Business
Architect, Business Optimizer, Web Publisher), ce qui fait augmenter les coûts.

Appréciation générale

Au delà de sa richesse fonctionnelle, cet outil tire profit de son intégration à une
gamme (la suite ARIS) couvrant toutes les étapes de l'optimisation des processus, du
suivi de la performance, de la simulation et du pilotage des processus.
La gestion des filtres permet de brider ses capacités pour l'adapter aux besoins des
utilisateurs.

79 de 273
3.6.4. iGrafx PROCESS

Descriptif
• Intégrant Flowcharter pour la partie cartographie, iGrafx Process permet de
modéliser les processus métiers de l'entreprise de manière simple et visuelle en y
ajoutant des données nécessaires aux fonctions de simulation.
• Publication immédiate au format Web avec une gestion des renvois hors pages
pour les diagrammes de grande dimension.
• Animation de processus pour visualiser la cinématique.
• Gestion de scénarios de simulation à partir d'un générateur de transactions
reposant sur de nombreux modèles et fonctions statistiques.
• Fourniture de processus références dans le domaine bancaire.
• La gestion centralisée d'un référentiel des procédures et des documents nécessite
le module iGrafx Process Central qui permet notamment :
• Le suivi des versions;
• La gestion des droits d'accès;
• Le partage de composants entre modèles;
• Le suivi des modifications.

Fiche d'identité
Prix par poste de 1 à 3 K€
Prix licence Serveur de 10 à 20 K€
Windows XP, 2000, ME, 98, NT 4.0
OS supportés
(sp 5+) Web serveur IIS
SGBD supportés SQL Server 2000 Standard Edition
Tableau 18 Fiche d'identité de iGrafx PROCESS

Résultas de l'évaluation

Fonction Note
Représentation graphique d'un processus 2
Production des procédures et modes opératoires 0
Fiche d'identité processus 3
Modélisation des interfaces entre processus 2
Contrôle des règles de représentation 1
Diffusion sur un portail Intranet 4

80 de 273
 Fonction Note
Contrôle de l'intégrité référentielle 1
Intégration du système d'information dans la représentation
2
processus
Intégration des moyens opérationnels à la représentation processus 2
Existence de rapports standards 0
TOTAL 17
Tableau 19 Résultas de l'évaluation de iGrafx PROCESS

Points Forts
• L'interface intuitive et la simplicité d'utilisation, notamment en matière de
publication.
• L'ouverture du produit qui lui permet par exemple d'importer des graphes Visio ou
d'incorporer des scripts VBA.
• L'intégration aux outils work flow et ScoreCard de Gedys.

Points Faibles
• Pas de référentiel des processus métier décrits par l'utilisateur.
• Pas de production, à partir des processus décrits, de documents des procédures et
modes opératoires.
• Le contrôle des règles de représentation (règles de syntaxe, cohérence des
graphes) n'est pas rigoureux.

Appréciation générale
Un positionnement intermédiaire entre les outils de cartographie et les outils
spécialisés de modélisation.
Si l'absence de référentiel processus peut s'avérer pénalisante, l'outil présente des
fonctions de simulation simples à mettre en œuvre qui permettent de mener des
analyses prévisionnelles dans des contextes simples.

81 de 273
3.6.5. MEGAProcess
Descriptif
• Couvre les besoins de modélisation des processus des organisations à partir de 3
cartes principales : les acteurs, les activités et les processus.
• La description du processus (sous forme de logigramme commenté) met en
évidence les relations du processus concerné avec les acteurs, les activités, les
procédures et les moyens informatiques de l'entreprise.
• Référentiel des processus et des acteurs.
• Quantification des ressources utilisées.
• Mesure et simulation de la performance.
• Génération de la documentation Qualité.
• Historisation des modifications.
• Analyse d'impacts.
• Gestion des accès par utilisateur et par base de données.
• Gestion multilingue du référentiel.
Fiche d'identité
Prix par poste de 3 à 5 K€
Prix licence Serveur de 2 à 5 K€
OS supportés Windows 9x / NT / 2000 / XP
SGBD supportés propriétaire
Tableau 20 Fiche d'identité de MEGA Process

Résultas de l'évaluation

Fonction Note
Représentation graphique d'un processus 5
Production des procédures et modes opératoires 5
Fiche d'identité processus 3
Modélisation des interfaces entre processus 5
Contrôle des règles de représentation 5
Diffusion sur un portail Intranet 3
Contrôle de l'intégrité référentielle 4
Intégration du système d'information dans la représentation
4
processus
Intégration des moyens opérationnels à la représentation processus 5
Existence de rapports standards 5
TOTAL 44
Tableau 21 Résultas de l'évaluation de MEGA Process

82 de 273
 Points Forts
• L'ergonomie.
• La prise en compte de la démarche Qualité.
• La mise à disposition de rapports permettant d'analyser les données du référentiel.
• Une structure de référentiel évolutive.

Points Faibles
• La génération de la documentation au sein d'un Intranet nécessite le module
complémentaire MEGA Intranet.
• Chaque utilisateur travaille sur un cache en local et décide du moment où il
répercute ses modifications sur le référentiel central, ce qui pose un problème de
synchronisation des modifications.

Appréciation générale
La version 2005 apporte de nombreux compléments intéressants, notamment en
matière de contrôle de cohérence inter-modèles et d'assistance méthodologique
(didacticiels, aide en ligne).
Un des outils de référence en matière de modélisation des processus métiers.

3.6.6. OSS@D Process Design

Descriptif
• Comme son nom l'indique, OSS@D DESIGN s'inspire directement de la méthode
OSSAD de description des organisations développée dans le cadre du projet
européen ESPRIT et qui est dans le domaine public.
• OSS@D PROCESS DESIGN permet une modélisation des processus à 3 niveaux
(les processus, les procédures et les opérations, les rôles et les acteurs) à partir
d'un référentiel.
• Le module se complète d'un portail documentaire, Process Portai, d'un module de
work flow Workey et d'un outil de gestion de connaissances MNESIK.
• Gestion des matrices acteurs / rôles.
• Possibilité de compléter la structure de la base de données par des données
personnelles.

83 de 273
 Export au format Word ou HTML.
Rapport d'évaluation de processus (présentée comme une fonction de simulation).
Fiche d'identité
Prix parposte < 1 K€
Prix licence Serveur de 2 à 5 K€
OS supportés Windows 9x, 2000, NT, XP
My SQL ou toute base ODBC / JDBC
SGBD supportés
Serveur Web ZOPE
Tableau 22 Fiche d'identité de OSS@D Process Design

Résultas de l'évaluation

Fonction Note
Représentation graphique d'un processus 4
Production des procédures et modes opératoires 3
Fiche d'identité processus 2
Modélisation des interfaces entre processus 4
Contrôle des règles de représentation 3
Diffusion sur un portail Intranet 4
Contrôle de l'intégrité référentielle 1
Intégration du système d'information dans la représentation
2
processus
Intégration des moyens opérationnels à la représentation processus 2
Existence de rapports standards 2
TOTAL 27
Tableau 23 Résultas de l'évaluation de OSS@D Process Design

Points Forts
• La simplicité.
• L'intégration à un module work flow abordable.

Points Faibles [531

• Pas d'intégration avec des outils tiers.
• Le contrôle de l'intégrité référentielle n'est pas assez rigoureux

Appréciation générale
Le choix de solutions technologiques en libre accès (base my SQL / serveur ZOPE)
rend ce type de solution particulièrement adapté à de petits budgets.

84 de 273
3.(5.7. QUALIGRAM Manager

Descriptif
• QUALIGRAM Manager comprend et complète les fonctionnalités de description de
QUALIGRAM Designer notamment dans les domaines :
• de la publication unitaire ou multiple des processus et procédures (au format Word,
HTML ou Microsoft Project);
• de la gestion des acteurs du système qualité (circuit d'approbation et de diffusion);
• des sécurités d'accès (par dossier, par graphe et par fonction du logiciel).
• Fonction "Présentation Web" permettant de générer en une seule opération
l'ensemble du manuel Qualité au format HTML (en intégrant les documents
externes ou les versions imprimables des processus et modes opératoires).
• Possibilité de rajouter des propriétés personnalisées aux éléments du processus.
• Définition d'indicateurs associables à tout élément du référentiel : mode de calcul,
valeur cible.
• Import des acteurs à partir d'un annuaire LDAP7 (Lightweight Directory Access
Protocol).
• Qualigram repose sur une méthodologie de description graphique des processus
inspirée de la méthode OSSAD.
• Un module complémentaire, en cours de beta test, permet d'exporter les modèles
au format XML.

Fiche d'identité
Prix par poste de 3 à 5 K€
Prix licence Serveur Non disponible
OS supportés Windows 9x / NT / 2000 / XP
SGBD supportés Access SQL Server Oracle
Tableau 24 Fiche d'identité de QUALIGRAM Manager

Résultas de l'évaluation

Fonction Note
Représentation graphique d'un processus 5
Production des procédures et modes opératoires 5
Fiche d'identité processus 3

7
F'rotocole de gestion d'annuaires de réseau, conçu à l'Université du Michigan, et reconnu par la plupart des
grosses sociétés du secteur.

85 de 273
 Modélisation des interfaces entre processus 4
Contrôle des règles de représentation 3
Diffusion sur un portail Intranet 4
Contrôle de l'intégrité référentielle 3
Intégration du système d'information dans la représentation
3
processus
Intégration des moyens opérationnels à la représentation processus 2
Existence de rapports standards 1
TOTAL 33
Tableau 25 Résultas de l'évaluation de QUALIGRAM Manager

Points Forts
• La simplicité d'utilisation tant pour décrire que pour éditer les cartographies et les
procédures.
• La clarté de la méthodologie et de sa mise en oeuvre.
• La variété et la qualité des rapports prédéfinis.
• La simplicité de la maintenance du référentiel Qualité.

Points Faibles
• Plutôt orienté « Qualité » que « Modélisation » proprement dite.

Appréciation générale
• Conçu par des spécialistes de l'approche Qualité, ce produit convient parfaitement
à la mise en place d'un système de gestion de la qualité, en particulier dans
l'optique d'une certification ISO version 2000.
• La possibilité d'exporter les modèles au format XML ouvre le produit vers des outils
amont (référentiel processus) ou aval (work flow, EAI8, GED9...).

3.7. Conclusion
Dans ce chapitre, nous avons évoqué la problématique de la prolifération, sur le
marché, de méthodes, outils et langages de modélisation, presque tous prétendant
répondre à tous les besoins de modélisation, et de la difficulté de choisir parmi cette
panoplie. L'objectif de ce chapitre a été de présenter un ensemble de méthodes et
d'outils de transformation inter-modèles actuellement sur le marché, d'essayer d'établir
une comparaison entre les méthodes, d'une part, et entre les outils d'autre part. Pour

8
Eînterprise Application Intégration. Intégration des applications dans l'entreprise.
9
Gestion Électronique de Documents
86 de 273
ces méthodes et outils de modélisation nous avons présenté leurs caractéristiques
fondamentales, leurs points forts et leurs points faibles. Il aurait été idéal d'aboutir, à la
suite de cette comparaison, à une méthode répondant à notre problématique, c'est-à-
dire une méthode de modélisation avantageuse à la fois en termes de facilité
d'utilisation, de rigueur dans la démarche et de complétude. Mais, cela s'avère
impossible. En effet, chaque méthode et chaque outil présentent des avantages et des
inconvénients. Ils sont de plus orientées vers des buts différents en terme d'utilisation et
principalement orientés vers le processus de développement de logiciel plutôt que vers
la modélisation des métiers des organisations.
En dépit d'apparentes similitudes, ces méthodes et ces outils différent largement en
termes de démarche, de vocabulaire, de domaine d'application, de formalisme, de
documentation produite et particulièrement pour les outils de modélisation, en termes
d'interfaces, de référentiels, de génération du code, de nombre de fonctions, de coûts,
etc. Il n'y a pas de standard pour le moment. Mais l'activité de standardisation des
processus métiers est en pleine effervescence et de nombreux progrès ont été
accomplis. La partie exécution des processus métier, sous l'égide de OASIS continue
sa fusion avec les services web; la partie conception remonte des préoccupations
d'exécution des processus vers des préoccupations plus résolument métiers. Plusieurs
organismes de standardisation participent à ce mouvement : BPMI.org (Business
Process Management Initiative) et OMG (Object Management Group). Il faudra encore
quelque temps pour que toutes les pièces du puzzle soient assemblées et rodées et
qu'un standard complet et unifié apparaisse clairement.
Selon le contexte initial de ce mémoire, nous devions nous limiter à déterminer laquelle
des méthodes étudiées s'adapte le mieux au contexte de l'administration québécoise.
C'est à dire une méthode applicable dans sa totalité, simple à utiliser, ne nécessitant
pas d'adaptations à chaque cas, n'exigeant pas d'expertise approfondie pour être
maîtrisée et axée sur les processus métier. Cependant, aucune n'a fait le poids, par
rapport aux critères établis (facilité, rigueur, complétude, orientation processus métier).
Une méthode (ou un outil) qui a fait ses preuves dans un domaine d'application peut
être inadéquate dans d'autres domaines. La situation d'ingénierie de chaque application
est différente. L'expérience a montré que les méthodes et les outils ne sont pas
universels et ils ne peuvent pas prévoir toutes les situations possibles. Les ingénieurs
d'application sont souvent amenés à les adapter pour pouvoir les appliquer dans le

87 de 273
contexte de leurs projets [21]. De plus, les méthodes et les outils ne sont pas toujours
suffisamment flexibles pour être facilement modifiés et adapté. Ce constat est bien
illustré dans le commentaire de Jean-Louis Bénard, fondateur de Brainsonic, réseau
d'experts en technologies de l'information. : «Les entreprises se constituent leur propre
méthodologie en agglomérant différentes pratiques».
Ce constat a également modifié la portée initiale de ce mémoire : Au lieu de choisir une
des méthodes énumérées dans ce chapitre, nous devons proposer une nouvelle qui
répond aux critères visés, à savoir, applicable dans sa totalité, simple à utiliser, ne
nécessitant pas d'adaptations à chaque cas, n'exigeant pas d'expertise approfondie
pour être maîtrisée et axée sur les processus métier. C'est ce que nous allons essayer
de démontrer dans le chapitre qui suit.

88 de 273
CHAPITRE 4 : CHOIX DE LA MÉTHODE

4,1. Introduction

Après ce tour d'horizon sur les méthodes et les outils de modélisation dans lequel nous
avons présenté leurs caractéristiques fondamentales et leurs points forts et points
faibles. La section suivante a pour but de faire le choix, pas simple à faire, de la
méthode qui nous paraît la plus adéquate pour mener la modélisation des processus
métier. Il aurait été idéal d'aboutir, à la suite de cette comparaison, à une méthode
répondant à notre problématique, c'est-à-dire une méthode de modélisation
avantageuse à la fois en termes de facilité d'utilisation, de rigueur dans la démarche et
de complétude. Mais, cela s'avère impossible. En effet, chaque méthode présente des
avantages et des inconvénients. Elles sont de plus orientées vers des buts différents en
terme d'utilisation et principalement orientées vers le processus de développement de
logiciel plutôt que vers la modélisation des métiers des organisations.
En plus de cet aspect orienté logiciel, les méthodes actuellement sur le marché sont
assez complexes. Cette complexité provient essentiellement du souci des concepteurs
de fournir des méthodes « universelles » qui s'appliquent à tous les cas. Ce souci
d'universalité est lui-même guidé par le souci de conquérir le plus de marchés
possibles. Le résultat est souvent contraire à l'objectif visé : Les analystes, ou de
manière générale ceux qui utilisent ces méthodes, se perdent dans la méandres de la
démarche préconisée et sont souvent obligés à procéder à des « réadaptations » de la
méthode choisie au contexte du problème à étudier. Des réadaptations successives
conduisent nécessairement à la prolifération de versions de la même méthode au sein
de la même organisation : Chaque version étant applicable à un cas spécifique et
partant, difficile à appliquer au cas suivant.

En tenant compte des critères analysés dans le chapitre 3 et de nos expériences

personnelles, il nous a paru, qu'à défaut d'une méthode universelle, il serait plus utile de
proposer une méthode simple, toujours applicable dans sa totalité et qui couvre
l'ensemble des activités nécessaires à la modélisation des processus métier.

89 de 273
4.2. Caractéristiques des méthodes utilisées au sein de l'administration
En 1999, une étude du Standish Group [65] portant sur un échantillon de 365
entreprises et 8 380 projets indiquait que parmi les projets informatiques lancés par les
entreprises, 16% seulement peuvent être considérés comme des succès (ils
aboutissent dans les délais et leur coût est celui qui avait été prévu), 31 % sont arrêtés
en cours de réalisation et 53 % aboutissent mais au prix d'un accroissement du délai et
du coût tout en offrant moins de fonctionnalités que prévu. Pour les grandes entreprises
(qui lancent proportionnellement davantage de gros projets), le taux de succès est de 9
% seulement, 37 % des projets sont arrêtés en cours de réalisation, 50 % aboutissent
hors délai et hors budget. Parmi les causes de succès, la première est l'implication des
utilisateurs qui expriment clairement leurs objectifs et formalisent leurs exigences selon
une démarche qu'ils comprennent; la seconde est l'implication des dirigeants dans le
soutien au projet. Parmi les causes d'échec, la première est la complexité des
méthodes utilisées, la deuxième est le manque de clarté des besoins et la troisième
est le changement des spécifications en cours de réalisation. De plus, La probabilité
d'échec est d'autant plus grande lorsque l'informatisation est menée en îlots (par projets)
sans une vision globale des PM de l'entreprise.

L'examen des causes de succès et d'échec est instructif : la plupart des échecs
proviennent non de l'informatique, mais de la compréhension et de la maîtrise, aussi
bien par les informaticiens que par les utilisateurs, des méthodes et des outils utilisés.
Dans l'administration, nous constatons que l'une des caractéristiques principales des
méthodes utilisées actuellement est leur complexité. Cette complexité est souvent liée à
de nombreux facteurs, notamment (d'après notre expérience) :
• Au langage utilisé, beaucoup plus proche du jargon des informaticiens que de celui
des premiers concernés (les utilisateurs);
• Au nombre de biens livrables produits (au Ministère de l'Éducation, nous avons
compté environ 30 documents à compléter);
• A la multiplicité des méthodes adoptées : la rigidité des méthodes oblige les
organisations à effectuer des adaptations successives de la même méthode en
fonction de la taille et la nature des projets;
• Au long processus d'apprentissage pour maîtriser la méthode et pour la réadapter;

90 de 273
• Au faible degré d'implication des utilisateurs: Les utilisateurs ne sont pas impliqués
dans toutes les étapes de la démarche. Au-delà des premières phases des
spécifications des besoins, leur rôle se limite à valider des biens livrables souvent
difficiles à lire (trop de termes techniques) et dont le nombre varie d'un projet à
l'autre.

Un autre facteur, ressenti au sein de l'administration, est qu'il y a tellement de travail à

fournir pour suivre la méthodologie que l'avancement du développement dans son
ensemble est ralenti et que la démobilisation des utilisateurs est provoquée. D'où le nom
qui leur est donné de « méthodologies lourdes » ou suivant le terme de Jim Highsmith:
« monumental méthodologies » [66].

Dans ce mémoire, nous ne prétendons pas inventer une nouvelle méthode qui résout
les problèmes des méthodes actuelles. Nous tenons essentiellement à tirer la sonnette
d'alarme sur ce dérapage «méthodologique » en posant certaines questions : Pourquoi
tant de complexité, si on peut simplifier ? Pourquoi continue-t-on à modéliser par projet
au lieu de le faire aussi selon une approche processus métier ? Pourquoi avons nous le
sentiment de progresser dans l'innovation « méthodologique » alors que c'est le
contraire qui est ressenti sur le terrain ? Pourquoi avons nous mis aux oubliettes les
acquis du passé, en adoptant une terminologie et des symboles sophistiqués pour
représenter des activités ou des éléments des processus métier, au lieu d'utiliser un
langage proche des utilisateurs (sinon le leur) ? À titre d'exemples, les ordinogrammes
et les symboles ANSI (American National Standard Institute) datant des années 70 ont
été largement acceptés par les utilisateurs car ils permettaient de bien représenter leur
métier.

Nous voulons également, dans ce mémoire, tirer la sonnette d'alarme sur les
conséquences des facteurs de complexité, cités auparavant, sur les dépenses de la
société québécoise dans le domaine de l'informatisation de l'administration. Il est
évident que des facteurs comme le délai d'apprentissage, les réadaptations
successives, le délai de réalisation, engendrent des coûts importants qui, si cumulés
pour l'ensemble de l'administration, s'élèveraient à des sommes faramineuses. Des
sommes qu'on peut économiser si nous révisons nos façons de faire actuelles.
91 de 273
 C'est pour ces raisons que nous allons, dans les sections suivantes, proposer une
démarche qui s'inspire beaucoup de l'acquis, notamment des approches d'analyse
structurée [[38], [41], [70]], en introduisant lorsque nécessaire, des concepts des
méthodes actuelles, tels que le diagramme de contexte (cf. Figure19), mais qui
demeurent à la portée d'utilisateurs non nécessairement informaticiens, tout en
cherchant la simplicité de la démarche, son ouverture pour de futures améliorations et
surtout son applicabilité intégrale quel que soit le PM à modéliser afin d'éviter les
réadaptations en fonction des spécificités de chaque processus métier.

4.3. Description de la méthode proposée

La méthode que nous proposons pour la modélisation des processus métier, ne prétend
pas être une nouvelle méthode créé du néant. Mais nous avons plutôt cherché à
construire une méthode combinant les meilleures pratiques en matière de modélisation
et ayant pour objectifs essentiels : La facilité d'emploi, la clarté dans la démarche, la
description de chaque activité à réaliser en déterminant qui fait quoi au sein de chaque
activité, qui en est responsable, quels sont les autres intervenants potentiels et aussi la
détermination des biens livrables que doit délivrer chacune des activités.
Un autre objectif et non des moindres, que nous avons visé, est que la méthode
proposée soit applicable dans son intégralité. Ainsi, ceux qui auront à l'utiliser n'auront
pas essayer de l'adapter à chaque nouveau cas d'étude qui se présente. Ceci constitue
un avantage majeur pour l'organisation, dans le sens où tout le monde utilisera la même
et unique méthode, quel que soit le processus métier à modéliser.
La méthode que nous proposons est composée des phases suivantes qui seront
décrites dans la suite de ce mémoire :
• Initialisation de l'étude
• Planifier l'initialisation de l'étude;
• Clarifier la demande;
• Préparer et présenter le rapport d'initialisation.
• Étude préliminaire
• Planifier l'étude préliminaire;

92 de 273
 • Recueillir l'information préliminaire sur le processus métier (PM) objet;
• Identifier les domaines;
• Identifier les processus métier;
• Définir la frontière du PM objet;
• Modéliser le contexte du PM objet;
• Préparer et présenter le rapport de l'étude préliminaire.
• Diagnostic de l'existant
• Planifier le diagnostic de l'existant;
• Analyser l'environnement;
• Collecter l'information sur le PM objet;
• Modéliser le PM objet;
• Établir le diagnostic;
• Préparer et présenter le rapport du diagnostic.
• Analyse
• Planifier l'analyse;
• Proposer des solutions;
• Obtenir les solutions retenues;
• Élaborer les nouveaux modèles du PM objet;
• Préparer et présenter le rapport d'analyse.

4.4. La phase d'initialisation de l'étude

La phase d'initialisation a pour but de réunir les conditions de succès de l'étude en

planifiant cette phase, en clarifiant la demande de modélisation, en précisant les
objectifs de modélisation et en définissant la structure de l'équipe de travail ainsi que les
rôles et responsabilité de chacun des membres.
Cette phase comporte 3 étapes :
• Planifier l'initialisation de l'étude et constituer l'équipe de travail;
• Clarifier la demande;
• Préparer et présenter le rapport d'initialisation.

93 de 273
 Livrable(s) attendu(s) :
• Planning de l'initialisation;
• Clarification de la demande;
• Rapport de la phase d'initialisation.
Acteur(s) responsable(s) :
• Chargé de projet;
Autre(s) intervenant(s) :
• Demandeur (requérant ayant formulé la demande de modélisation);
• Principaux gestionnaires affectés par le processus métier objet de la demande;
• Utilisateur(s) connaissant bien le domaine de l'étude.

4.4.1 Planifier l'initialisation de l'étude

Chaque étape d'un projet doit être planifiée avec soin. Le degré de formalisme de cette
planification varie selon l'ampleur du projet et selon la complexité du processus métier
en cause. Essentiellement, la planification de la phase d'initialisation consiste à se
familiariser avec le processus métier et l'organisation dont il fait partie, à déterminer le
profil et la composition de l'équipe qui mènera cette phase, notamment les ressources
qui permettront de clarifier la demande de modélisation et qui fourniront davantage
d'informations sur les objectifs à atteindre.

Livrable(s) attendu(s) :
• Planning de l'initialisation comportant la liste des personnes ressources, leurs
coordonnées, leurs rôles, leurs responsabilités ainsi qu'un planning des rencontres.
Acteur(s) responsable(s) :
• Chargé de projet;
Autre(s) intervenant(s) :
• Demandeur;
• Principaux gestionnaires affectés par le processus métier objet de la demande.

94 de 273
4.4.2 Clarifier la demande

Les demandes sont parfois énoncées de façon très générale, ce qui peut porter à
confusion. La clarification de la demande a pour objectif de s'assurer que l'équipe de
travail a une compréhension de la demande qui correspond à celle du demandeur, de
définir de façon adéquate le processus métier faisant l'objet de la demande et de saisir
les éléments essentiels de son environnement.
La clarification de la demande s'effectue principalement par des rencontres avec le (ou
les) demandeurs), puis avec les principaux gestionnaires dont les départements sont
affectés ou influencés par le processus métier à l'étude.
En plus de viser à bien cerner en quoi consiste la demande et à définir le processus
métier dont il est question, ces rencontres serviront à établir une première liste de
problèmes, de risques et d'occasions d'amélioration. Ces éléments seront d'une grande
utilité lors de la phase de diagnostic.
A l'issue de ces rencontres, un rapport est rédigé et soumis à la validation du
demandeur avant d'aborder l'étape suivante.

Livrable(s) attendu(s) :
• Comptes rendus des rencontres validés par le demandeur;
• Description sommaire décrivant la demande, le processus métier objet de la
modélisation et de son environnement et les objectifs de la demande.
Acteur (s) responsable(s) :
• Analyste;
Autre(s) intervenant(s) :
• Demandeur;
• Principaux gestionnaires affectés par le processus métier objet de la demande.

4.4.3 Préparer et présenter le rapport d'initialisation

Le rapport d'initialisation permettra aux décideurs et aux membres de l'équipe de travail

de déterminer si la compréhension de la demande et des objectifs fixés est la même
pour tous. Bien souvent, les auteurs du rapport en font une présentation orale au cours

95 de 273
 de laquelle les participants pourront demander des éclaircissements ou apporter des
correctifs.

Livrable(s) attendu(s) :
• Rapport de la phase d'initialisation regroupant les livrables issus des étapes de la
planification et de la clarification de la demande sans omettre d'y adjoindre les
commentaires et les rectificatifs émis à l'issue de la présentation du rapport;
Acteur(s) responsable(s) :
• Analyste;
Autre(s) ïntervenant(s) :
• Néant

En résumé, le diagramme de la Figure 17 présente les étapes et les produits de la

phase d'initialisation. Toutes les étapes décrites sont itératives, c'est à dire qu'à chaque
niveau (défini par le numéro de l'étape), il est possible de retourner au niveau précédent
pour complément d'information ou pour actualiser ce dernier en cas d'omission ou
d'apparition de nouveaux éléments qui conduisent à une révision de ce qui a été conçu
auparavant.
Demande de modélisation
(Définition Su PM a modéllser et
des objectifs de modélisation)

1.1 Planifier l'Initialisation 1.2 Clarifier la demande •ésenter

1.3 Préparer et préseï
le rapport de l'initialisation I

Plannining de l'initialisation Comptes rendus des rencontres

Liste des membres de l'équipe de travail Description de la demande et Rapport de Ea phase
(coordonnées, rôles, responsabilités) du PM a modêllser d'Initialisation
Planning des rencontres Objectifs de la demande

Figure 17 Activités et produits de la phase d'initialisation

96 de 273
4.5. La phase d'étude préliminaire

L'étude préliminaire consiste à circonscrire le processus métier sur lequel porte la

demande en fonction des objectifs identifiés lors de la phase d'initialisation, à cerner les
principaux problèmes, à estimer l'ampleur du projet et des changements probables.
Dans toute la suite de ce document, nous désignerons le processus métier existant par
les termes PM objet.
Lors de cette phase, on procède à un recueil d'informations préliminaires (informations
pour comprendre le processus), puis on cherche à identifier les principaux domaines
gérés par l'Unité Organisationnelle (UO), ensuite pour chaque domaine, on procède à
une identification des processus métier qui le composent; puis on définit la frontière du
PM objet (ce qui en fait partie et ce qui ne l'est pas). Ensuite on élabore un modèle de
contexte et finalement on prépare le rapport d'étude préliminaire en vue de le présenter
aux décideurs.
L'identification des différents domaines relevant de la mission de l'organisation
considérée ainsi que les différents processus métiers qui les composent a pour but de
situer le PM objet de l'étude par rapport aux autres processus métier de l'organisation.
Ce positionnement du PM objet par rapport aux autres processus métier pourrait révéler
des liens (ou même des redondances) entre processus métier.

La phase de l'étude préliminaire est composée de 7 étapes :

• Planifier l'étude préliminaire;
• Recueillir l'information préliminaire sur le PM objet;
• Identifier les domaines;
• Identifier les autres processus métiers;
• Définir la frontière du PM objet;
• Modéliser le contexte du PM objet;
• Préparer et présenter le rapport de l'étude préliminaire.

97 de 273
4.5.1 Planifier l'étude préliminaire

L'objectif de cette étape est de déterminer les sources et les méthodes de collecte
d'information qui seront utilisées ainsi que le planning des rencontres avec les acteurs
impliqués. Cette planification variera selon l'ampleur et la complexité du PM objet en
cause. Ainsi, il est fort probable que l'étude préliminaire d'une organisation de taille
réduite exigera la collaboration d'un nombre inférieur de sources d'information que celle
d'un processus métier d'envergure d'une entreprise de grande taille. Pour un processus
métier d'envergure, où plusieurs personnes sont engagées dans l'étude préliminaire, il
s'agira aussi de définir les tâches et les responsabilités de chaque participant et de
décider des moyens de coordination de ces tâches.

Livrable(s) attendu(s) :
• Planning de l'étude préliminaire comportant l'échéancier des activités de cette étape,
la liste des sources d'informations et les méthodes de collecte d'information à utiliser
(entrevues, questionnaires, observation ou sondages).
Acteur(s) responsable(s) :
• Analyste;
Autre(s) intervenant(s) :
• Demandeur;
• Principaux gestionnaires affectés par le processus métier objet de la demande.

4.5.2 Recueillir l'information préliminaire sur le PM objet

Cette étape consiste à effectuer le repérage des informations fonctionnelles et

opérationnelles sur le PM objet. Les informations recueillies (selon les outils de collecte
adoptés : entrevues, questionnaires, observation, lecture de la documentation
disponible) sont transcrites principalement sous forme de textes ou de diagrammes très
simples et de haut niveau. Elle prépare les activités plus formelles de capture des
besoins fonctionnels décrites plus loin (cf. 4.6.3).
Le but de cette étape est de développer une compréhension commune sur le PM objet.
Il s'agit d'identifier les différentes composantes du PM objet à un niveau d'abstraction
98 de 273
élevé. Ce niveau d'abstraction part des objectifs du PM objet considéré dans son
ensemble, en déterminant ses grandes fonctions, les principaux services qu'il offre, les
principales sorties (outputs) qu'il met à la disposition de ses clients et les principales
entrées (inputs) qu'il reçoit des fournisseurs. Toutes ces informations sont recueillies
auprès du demandeur, des principaux gestionnaires affectés par le PM objet et
éventuellement auprès de personnes connaissant bien le PM objet. Pour compléter sa
compréhension du PM objet, l'analyste s'attachera à recueillir aussi de l'information sur
la mission de l'UO, ses politiques, ses orientations et ses règles.
Ce recueil d'informations préliminaires peut aussi être l'occasion pour détecter les
principaux problèmes perçus par les différents intervenants lors des entrevues. Ces
éléments seront d'une grande utilité lors de la phase du diagnostic.

La démarche proposée lors de cette étape est la suivante :

• Collecte et lecture de la documentation sur l'UO (organigramme, description des
missions, énoncés des règles, stratégies, orientations, etc.);
• Entrevue des personnes-clé connaissant bien l'UO, son fonctionnement, ses règles,
etc.;
• Rédaction des résumés des entretiens;
• Validation des résumés des entretiens.

Comme nous l'avons annoncé précédemment, il existe quatre principaux d'outils de

collecte de l'information : l'entrevue, les questionnaires, l'observation et la
documentation de l'organisation. Tous ces outils n'auront pas à être utilisés dans toutes
les situations. Les questionnaires, par exemple, sont surtout utiles pour obtenir des
renseignements précis sur un PM ou sur son environnement, et cela auprès d'un grand
nombre de personnes. Dans certains cas, l'observation est utile pour voir comment un
processus fonctionne ou comment les usagers l'utilisent. L'entrevue et la documentation
sont des outils utilisés dans toutes les circonstances et quelle que soit l'envergure du
projet.

Livrable(s) attendu(s) :
• Résumé des comptes rendus;

99 de 273
 • Résumé sur la mission de l'UO, ses politiques, ses orientations et ses règles;
• Liste des principales fonctionnalités du PM objet, ses principales entrées/sorties, ses
principaux clients/fournisseurs;
• Problèmes perçus par les personnes consultées;.
Acteur(s) responsable(s) :
• Analyste;
Autre(s) intervenant(s) :
• Demandeur;
• Principaux gestionnaires affectés par le processus métier objet de la demande;
• Personnes connaissant bien le PM objet.

4.5.3 Identifier les domaines

Le but de cette étape est de développer une compréhension commune de la structure et

de la dynamique des affaires de l'organisation dans laquelle se situe le PM objet. Il
s'agit d'identifier les différentes composantes de l'UO à un niveau d'abstraction élevé.
Ce niveau d'abstraction part de l'organisation considérée dans son ensemble, la
découpe en domaines de production de valeurs qui reproduisent souvent, le découpage
de l'organigramme en grandes directions; puis il identifie (cf. 4.5.4) les divers processus
métier de chacun des domaines. Ce découpage permettra de situer le PM objet par
rapport aux autres processus faisant partie du même domaine ainsi que par rapport aux
autres processus métier des autres domaines : l'intérêt est de pouvoir déceler des liens
éventuels inter-processus métier. Ces liens serviront par la suite à identifier les
échanges entre le PM objet et d'autres PM de l'organisation considérée.
Idéalement, un recueil d'information exhaustif sur l'organisation en entier fournirait une
vue complète de l'ensemble des domaines et des processus métier existants. Mais
compte tenu de la complexité et de l'étendue des administrations québécoises, un tel
recueil est quasi utopique, ne serait-ce que par le temps nécessaire pour mener cette
opération et par les ressources à mobiliser. Pour être pratique, nous préconisons un
recueil d'information par unité organisationnelle. Selon F.B. Vernadat [54], une Unité
Organisationnelle (UO) est un composant d'une structure organisationnelle (direction,
service, poste, etc.) à laquelle sont affectées des responsabilités, voire des autorités.

100 de 273
 Cette étape qui s'inscrit dans le prolongement du recueil de l'information, vise à
identifier les domaines existant au sein de l'UO. Selon F.B. Vernadat [54], un domaine
est un élément structurant permettant de regrouper un ensemble de processus et les
ressources associées en un module fonctionnel indépendant tels que Achats,
Production, Commercialisation, Maintenance, etc.
Pour mener à bien cette activité, nous nous basons sur l'analyse des informations
recueillies, sur l'avis des personnes consultées et également sur le diagramme
d'organisation souvent appelé organigramme. Ce diagramme n'est pas un diagramme
UML mais il nous semble très important car il n'est pas possible de s'affranchir de la
structure d'une UO pour identifier ses domaines. Le diagramme d'organisation permet
de donner une vision générale sur la structure et la hiérarchie de l'UO en question.
Prenons l'exemple d'une UO dénommée « Gestion de la production» (Figure 18).
D'après son organigramme, ses principaux services utilisateurs sont le service
commercial, le service de production et le service des achats. Les autres départements
tels que les ressources humaines et l'informatique sont hors périmètres car ils n'utilisent
pas directement le système « Gestion de la production ». On peut facilement déduire
que son domaine global comprend les domaines Commercial, Production et Achats.

Gestion de la
production

Service commercial Service de production Service des achats

Bureau de la gestion Bureau de la gestion Bureau de la Bureau de la

des clients des commandes logistique fabrication

Figure 18 Exemple de diagramme d'organisation d'une UO

Lorsque les domaines sont identifiés et validés par les personnes consultées, on
propose de dresser leur liste avec une brève description et en adoptant une codification
permettant de retrouver facilement l'UO en question et les domaines rattachés, comme
illustré dans le tableau suivant :

101 de 273
 Liste des domaines Date : 2004-06-
Fiche 01
25
Unité
Direction de la gestion de la production
organisationnelle

Code unité UO01

Code domaine Domaine Description

• • • • • • •

Gestion des clients et des

UO01_D01 Commercial
commandes des clients.
Gestion de l'atelier de la
UO01_D02 Production fabrication et de la logistique
nécessaire à la production.
Gestion des achats des
UO01_D03 Achats matières premières et des
approvisionnements.

Tableau 26 Liste des domaines de I'UO « Gestion de la production »

Livrable(s) attendu(s) :
• Fiche 01 : Liste des domaines
Acteur(s) responsable(s) :
• Analyste;
Autre(s) intervenant(s) :
• Demandeur;
• Personnes connaissant bien I'UO.

4.5.4 Identifier les processus métier

Pour chaque domaine tel que décrit dans le Tableau 26, il s'agit d'identifier les
processus métier qui le composent. Selon Chantai Morley [55] « Un processus métier se
définit comme un ensemble finalisé d'activités orientées vers la production d'une valeur
pour un client. Il a pour but d'accomplir une mission du domaine. Des acteurs externes
ont une visibilité sur ce type de processus ». Cette définition est intéressante car elle

102 de 273
 vise à centrer l'organisation des activités sur le service rendu au client, faisant passer au
second plan les contraintes et les frontières internes du domaine analysé.
Il faut avouer qu'il n'y a pas de recette miracle pour identifier les processus métier.
Toutefois, la majorité des processus sont implicitement identifiables par la nature même
du domaine considéré. Pour cela, on s'appuie sur la documentation collectée, sur la
description du domaine et sur l'avis des personnes connaissant bien le domaine.
Le résultat de cette activité est la liste des processus métier composant chaque
domaine identifié et validée par les experts du domaine. Nous proposons d'établir une
liste comme celle illustrée dans le Tableau 27 ci-après.
Liste des processus métier Date : 2004-
Fiche 02
06-25
Unité Direction de la gestion de la
Code unité : U01
organisationnelle production

Domaine Commercial Code domaine : U01_D01

option
Gérer toutes les informations
sur les clients (références,
UO01_D01_P01 Gestion des clients
historique, solvabilité, crédit,
débit, etc.).
Recevoir les commandes des
clients, préparer les
commandes, livrer la
Gestion des commandes marchandise, établir les
UO01_D01_P02
des clients factures, recevoir les
payements, vérifier la
disponibilité des produits,,
acheter des produits, etc.

Tableau 27 Liste des processus métier du domaine « Commercial »

Livrable(s) attendu(s) :
• Fiche 02 : Liste des processus métier avec une description sommaire
103 de 273
 Acteur(s) responsable(s) :
• Analyste;
Autre(s) intervenant(s) :
• Demandeur;
• Personnes connaissant bien le domaine.

4.5.5 Définir la frontière du processus métier objet

D'un point de vue théorique, déterminer la frontière est une tâche qui se décrit
simplement: il s'agit de distinguer ce qui fait partie du processus à l'étude de ce qui n'en
fait pas partie. Il s'agit donc de déterminer les entrées (inputs) et leurs sources, les
sorties (outputs) et leurs destinations, les services et les personnes impliqués dans ces
activités, les activités qui composent le processus ainsi que les processus qui
interagissent avec le processus à l'étude.
En pratique, pourtant, il s'agit sans doute de l'une des tâches les plus critiques et les
plus délicates d'un projet, et cela pour plusieurs raisons. C'est une tâche critique
puisque si l'on définit la frontière de façon trop restreinte, le risque est grand que des
éléments essentiels soient laissés pour compte. Par contre, une frontière trop étendue
aura aussi des conséquences négatives. Bien qu'elle permette de s'assurer qu'on a pris
en compte tous les éléments importants du processus, ceux qui l'influencent et ceux qui
sont influencés par lui, une telle définition aurait pour effet d'augmenter, de façon
importante, le temps et le coût de l'étude, de même que la complexité de l'analyse qui
s'ensuivra.

Il n'existe pas de recette miracle pour guider la définition de la frontière d'un processus
métier. Selon plusieurs, il s'agit là de l'une des tâches les plus difficiles qu'aura à
accomplir l'analyste. Peu importe le processus que l'on définit, il fera partie d'un
processus plus vaste. En un mot, la détermination de la frontière du processus à l'étude
relève plus de l'art que de la science; c'est pourquoi cette tâche requiert l'exercice du
jugement et, souvent, de l'expérience. L'une des recommandations les plus pratiques
que l'on puisse faire est d'utiliser les résultats de la clarification de la demande, au cours
de laquelle on aura tenté de cerner le plus grand nombre de problèmes et d'occasions
d'amélioration. La frontière devrait englober les activités qui sont concernées par les

104 de 273
 problèmes, ou qui en sont des sources potentielles, et celles qui pourraient bénéficier
des améliorations. Harrington [67] suggère certaines questions additionnelles qui
peuvent orienter la détermination de la frontière. Où devraient commencer et s'arrêter
les préoccupations du propriétaire du processus? Qui sont les clients (que nous
appèlerons acteurs,) du processus? Où commence l'implication des acteurs du
processus et où se termine-t-elle?
Le résultat de la définition de la frontière du processus est le Tableau 28 qui consiste en
une description sommaire des composantes du processus métier objet. Pour le bâtir,
nous nous basons principalement sur la clarification de la demande (cf. 4.4.2), sur le
recueil de l'information préliminaire (cf. 4.5.2), sur l'identification des domaines (cf.
4.5.3) et sur l'identification des processus métier (cf. 4.5.4). Il n'est pas nécessaire de
détailler cette étape car elle le sera davantage lors de la modélisation du contexte (cf.
4.5.6), notamment en ce qui concerne l'identification des acteurs, des messages
échangés et des activités principales. Ces notions seront encore plus détaillées lors de
la phase du diagnostic, notamment à l'étape de la poursuite de la collecte de
l'information sur le processus métier objet (cf. 4.6.3).

Composante Description
Liste des entrées telles que Commande, Payement,
Entrées
Approbation, etc.
Acteurs (Fournisseurs des Liste des acteurs ayant fourni les entrées telle que Client,
entrées) Contrôleur, autre processus métier, etc.
Liste des sorties produites par le processus métier objet
Sorties telles que Facture, Rapport statistique, État du compte
client, etc.
Acteurs (Destinataires des Liste des acteurs destinataires des sorties telle que Client,
sorties Département des ventes, autre processus métier, etc.
Description sommaire de l'activité générale du processus
Activités
métier objet.
Acteurs effectuant les tâches au sein du processus métier
Acteurs effectuant les activités objet tels que Réceptionniste, Comptable, Supérieurs qui
du PM objet approuvent les commandes, Secrétaire qui fait la saisie
des factures, etc.
Liste des activités exclues du processus métier objet telle
Activités exclues du PM objet que Traitements effectués par la banque, Expédition des
produits livrés, etc.

Tableau 28 Les déterminants de la frontière du processus métier objet

105 de 273
 Livrable(s) attendu(s) :
• Tableau 28: Les déterminants de la frontière du processus métier objet
Acteur(s) responsable(s) ;
• Analyste;
Autre(s) intervenants) :
• Demandeur;
• Principaux gestionnaires affectés par le processus métier objet de la demande;
• Personnes connaissant bien le PM objet.

4.5.6 Modéliser le contexte du PM objet

Cette étape a pour but de modéliser le contexte du PM objet. À ce stade, le processus

est considéré comme une boite noire (on ne s'intéresse pas au comment se font les
choses) et il s'agit alors de compléter l'identification (abordée lors de la définition des
frontières du PM objet) des acteurs qui interagissent directement avec le processus
métier, ainsi que leurs interactions (messages échangés) en représentant l'ensemble
des interactions sur un modèle de contexte dynamique similaire à celui présenté dans la
Figure 19.
Notons qu'en matière de modélisation métier, Jacobson [46] a été le premier à proposer
d'utiliser les concepts UML d'acteurs, de cas d'utilisation (CU), de classe, de package,
etc. avec des stéréotypes particuliers. Dans la suite de ce mémoire nous utiliserons les
stéréotypes présentés dans le Tableau 29 ci-dessous, qui sont inspirés de ceux fournis
par Rational/Rose [56]. Si d'autres stéréotypes étaient nécessaires nous les introduirons
au moment opportun.

106 de 273
 Stéréotype
Description
Rational/Rose

Cas d'utilisation (CU) stéréotypé appelé processus métier.

Acteur humain stéréotypé représentant une entité externe à

X l'entreprise.

X Acteur non humain stéréotypé représentant une entité

externe à l'entreprise.

Classe stéréotypée représentant un acteur humain agissant

à l'intérieur de l'entreprise.

® Classe stéréotypée représentant un acteur non humain

agissant à l'intérieur de l'entreprise.

Classe stéréotypée représentant une entité passive

manipulée par un acteur.

Package stéréotypé structurant le modèle métier.

Tableau 29 Stéréotypes proposés par Rational Rosé [56]

La démarche proposée lors de la réalisation de cette activité est la suivante :

• Identifier les acteurs : Un acteur représente l'abstraction d'un rôle joué par des
entités externes (utilisateur, dispositif matériel ou autre système) qui interagissent
directement avec le système étudié [49];
• Identifier les messages : Un message représente la spécification d'une
communication qui transporte de l'information avec l'intention de déclencher une
activité chez le récepteur [49];
• Pour chaque acteur, il faut alors se demander quels sont les messages qui
déclenchent un comportement du PM objet attendu par l'acteur dans le cadre de son
activité.

107 de 273
 Il faut également se demander quels sont les messages émis par le PM objet à
l'intention des acteurs et qui portent une information utilisée par ces derniers.
• Modéliser le contexte : Tous les messages (du PM objet <~>acteurs) identifiés
précédemment peuvent être représentés de façon synthétique sur un diagramme
que l'on qualifie de diagramme de contexte [49] comme illustré dans la Figure 19.
Dans ce diagramme, le processus métier est représenté par un objet central entouré
par d'autres objets symbolisant les différents acteurs. Sur chaque lien entre le
processus métier et les acteurs sont montrés les messages en entrée et en sortie
sans trop de détails pour ne pas encombrer le diagramme et le rendre illisible.
Pour montrer les résultats de cette étape, nous allons nous baser sur un exemple
simplifié du PM objet « Gestion des commandes des clients » (cf. Tableau 26). Pour cet
exemple, nous avons imaginé que, d'après les informations recueillies lors des étapes
précédentes, toute commande qui provient d'un client est prise en charge par ce PM.
À son arrivée, la commande du client est enregistrée dans un registre. Ensuite, une
copie est envoyée au PM « Gestion des clients » qui vérifie la solvabilité du client et
retourne cette information au PM « Gestion des commandes des clients ». Si le client
n'est pas solvable, il reçoit alors un avis de refus. S'il est solvable, la livraison est
préparée puis envoyée au client accompagnée d'un bon de livraison. À la suite de cette
livraison, une facture est établie et envoyée au client. Ce dernier envoie alors le
payement.
Si la marchandise n'est pas disponible, elle est alors commandée auprès d'un
fournisseur qui livre les produits accompagnés d'un bon de livraison. Une fois les
produits reçus du fournisseur, on procède alors à son payement.
Toute commande traitée est envoyée aux service des archives pour historique et
conservation.
Une fois l'information collectée et analysée, les domaines et leur processus identifiés,
nous proposons de dresser le Tableau 30 listant les acteurs et les messages échangés
avec le processus métier. Nous tenons à rappeler, encore une fois, que le PM objet est
vu comme une boite noire à ce stade de l'étude. Par conséquent, nous nous intéressons
uniquement aux acteurs externes au PM objet et non aux intervenants « internes » qui
effectuent les tâches au sein du PM Objet. Ces derniers seront pris en compte lors de la
phase de diagnostic de l'existant.

108 de 273
Fichs 03 Liste des acteurs externes Date : 2004-06-25

Direction de la gestion
Unité organisationnelle Code unité : U01
de la production

Domaine Commercial Code domaine : U01_D01

Gestion des
Processus métier Code processus : UO01_D01_P02
commandes

Code acteur Acteur Description (intention/Service attendu)

Émet : Commande, payement.

Commander des produits et se faire livrer ces
UO01_D01_P02_AC01 Client Reçoit : Marchandise, bon de
produits.
livraison, facture.

Émet : Produit, bon de livraison,

UO01_D01_P02_AC02 Fournisseur Foumir les produits commandés et se faire payer. facture.
Reçoit : Commande, payement.

PM « Gestion des Compléter ou créer l'information sur le client et Émet : Solvabilité du client.
UO01_D01_P02_AC03
clients » informer sur la solvabilité du client. Reçoit : Copie de la commande.

PM « Gestion des Archiver les commandes et créer l'historique des

UO01_D01_P02_AC04 Reçoit : Copie de la commande.
archives » commandes.

Tableau 30 Liste des acteurs du processus métier « Gestion des commandes »

109 de 273
 Après avoir défini les acteurs et les messages échangés avec le système, le
diagramme de contexte se présente comme montré dans la Figure 19 ci-après:

Commande Commande
Client Payement
Payement ournisseur
Marchandise Produit
Bon livraison Bon Livraison
Facture Gestion des
commande
Refus Copie commande

Commande
Solvabilité Gestion des / \
Gestion des
client ( clients / )
archives

Figure 19 Diagramme de contexte du processus métier «Gestion des commandes »

Livrable(s) attendu(s) :
• Tableau 30 : Liste des acteurs du processus métier et des messages échangés;
• Figure 19 : Diagramme de contexte.
Acteur(s) responsable(s) :
• Analyste.
Autre(s) intervenant(s) :
• Demandeur;
• Personnes connaissant bien le PM objet.

4.5.7 Préparer et présenter le rapport de l'étude préliminaire

Le rapport de l'étude préliminaire est un document important puisqu'il permettra aux
différents intervenants (décideurs, utilisateurs, analystes, etc.) d'avoir une vision

110 de 273
 commune sur le processus objet, sur ses objectifs, sur sa frontière, sur les différents
acteurs qui interagissent avec le PM objet, sur les entrées (inputs) et leurs sources et
sur les sorties (output) et leurs destinations. Le PM objet étant considéré à ce stade
de l'étude comme une boite noire, nous ne nous intéressons pas au comment il
fonctionne en terme d'activités (fonctions accomplies), ni à ses acteurs internes, ni
aux flux de messages échangés entre ces derniers. Ces notions seront abordées lors
de la phase suivante (Diagnostic de l'existant) et plus précisément lors de l'étape de
modélisation du PM objet.
En ce qui concerne le rapport de l'étude préliminaire, il doit constituer une compilation
des biens livrables élaborés à l'issue de chacune des étapes de l'étude préliminaire;
et bien souvent les auteurs en feront une présentation orale au cours de laquelle les
décideurs pourront demander des éclaircissements, émettre des commentaires et
apporter des correctifs. Dans le Tableau 31, nous proposons un exemple de table de
matière pour ce rapport.
Sommaire
1. Rappel de la demande
• Requérant (Personne ayant formulé la demande);
• Description sommaire du processus métier objet de l'étude;
• Problème(s) identifié(s) par le requérant.
2. Méthodologie de l'étude préliminaire
• Outils de collecte d'information;
• Personnes rencontrées.
3. Le contexte
• Profil organisationnel: Structure, politiques, personnel, applications
• Profil technologique: équipements;
4. Le processus métier objet à l'étude
• Identification - frontière - description générale;
• Rappel de la mission des services impliqués et des objectifs de leurs
gestionnaires;
• Objectifs du requérant;
• Identification des processus qui interagissent avec le processus à l'étude;
• Détermination des activités composant le processus ainsi que les
services et les personnes impliqués;
• Identification des inputs et leurs sources, et des outputs et leurs
destinations.
5. Modèle du contexte
• Diagramme de contexte du PM Objet.
6. Problèmes
• Problèmes perçus par le propriétaire du processus et les gestionnaires
concernés;
• Problèmes perçus par l'analyste.
111 de 273
 7. Description des tâches à accomplir pour la suite de l'étude.

Tableau 31 Exemple de table des matières pour le rapport d'étude préliminaire

A la suite de la présentation du rapport de l'étude préliminaire et de sa validation par

le demandeur et les principaux gestionnaires, nous pourrons débuter la phase de
diagnostic.
En résumé, le diagramme présenté dans la Figure 20 résume les étapes et les
produits de l'étude préliminaire. Toutes les activités décrites sont itératives, c'est à
dire qu'à chaque niveau (défini par le numéro de l'étape), il est possible de retourner
au niveau précédent pour complément d'information ou pour actualiser ce dernier en
cas d'omission ou d'apparition de nouveaux éléments qui conduisent à une révision
de ce qui a été conçu auparavant.

2.1 Planifier l'étude 2.2 Recueillir rlnformstlon 2.3 identifier 2 4 Mentir» le! 2.6 Définir la frontière 2.6 Modéllser le cadette 2.7 Préparer et présenter
prailmlnaire préliminaire sur le PM objet les domaines processus métier I ou PM objet | du PM objet | te rapport de l'étude préliminaire

Pliinning de l'étude préliminaire Liste des processus métier Déterminants de la Liste des acleurs et des Rapport de l'étude
u n e des sources d'Information frontière du PM objet messages échangés préliminaire
Mt Ihode(s) de collecte d'information - Diagramme de contexte

Résumé des comptes rendus

Résumé sur la misston de l'UO
(politique, régies, orientations, etc.)
Liste des principales fonctionnantes
du PM objet et ses principales entrées/sorties
Liste des problèmes perçus

Figure 20 Activités et produits de l'étude préliminaire

112 de 273
4.6. La phase du diagnostic de l'existant
Les principaux objectifs du diagnostic de l'existant sont de définir les modèles du PM
objet, d'énumérer les problèmes et leurs causes ainsi que les objectifs que devrait
atteindre le PM objet une fois transformé et de suggérer quelques éléments de
solution qui permettraient d'atteindre ces objectifs. Pour ce faire, l'analyste ou l'équipe
d'analyse devra acquérir une excellente connaissance de l'environnement
organisationnel et bien comprendre le PM objet et son fonctionnement.
La méthode décrite dans ce mémoire décompose le diagnostic de l'existant en six
étapes. Après avoir planifié le travail à effectuer, les acteurs du diagnostic doivent se
familiariser davantage avec le PM objet et son environnement (familiarisation déjà
amorcée lors de l'étude préliminaire) afin d'être en mesure d'identifier les contraintes
que cet environnement pose, de même que les opportunités qu'il offre. Il s'agira
ensuite de recueillir une quantité importante d'information au sujet du PM objet et
d'en faire la modélisation. Par la suite, l'équipe de travail sera en mesure de poser le
diagnostic, c'est-à-dire d'identifier les problèmes et leurs causes. Un rapport faisant
état du diagnostic sera présenté aux mandataires de l'étude et à l'équipe de direction
de l'organisation.
Les étapes de cette phase sont itératives. En effet, il se peut qu'au moment de pro-
céder au diagnostic on se rende compte qu'il manque certains éléments d'infor-
mation, que ce soit au sujet du processus ou de son environnement. Il faudra alors
reprendre certaines tâches de collecte d'information. Il se produit même parfois que,
lors de la présentation du rapport, de nouveaux éléments apparaissent et que
certaines des tâches soient à reprendre. Bien qu'une telle situation ne soit pas
agréable, il est préférable qu'elle survienne au moment de la présentation des
résultats du diagnostic que lors de la présentation du nouveau PM.
Les étapes proposées pour mener cette phase sont :
• Planifier le diagnostic de l'existant;
• Analyser l'environnement;
• Collecter l'information sur le PM objet;
• Modéliser le PM objet;
• Établir le diagnostic;
• Préparer et présenter le rapport du diagnostic.
113 de 273
4.6.1 Planifier le diagnostic de l'existant

Avant que ne commence l'activité de diagnostic proprement dite, le responsable de la

présente étape doit planifier le travail à effectuer. Ceci consiste, principalement, à
former l'équipe de diagnostic, à répartir les rôles et les responsabilités, à choisir les
outils et techniques qui seront utilisés et à élaborer un échéancier.

4.6.1.1 Former l'équipe

La composition finale de l'équipe dépendra de plusieurs facteurs : l'envergure du PM

objet, la taille de l'organisation, la disponibilité et l'expérience des intervenants
potentiels. Il est essentiel que les personnes engagées dans le PM objet et/ou
l'utilisant jouent un rôle important dans l'étude en cours, puisque ce sont elles qui
auront la responsabilité de s'assurer que les nouvelles façons de faire répondront aux
besoins d'affaires de leur organisation. De plus, comme elles connaissent bien les
tâches qui composent le PM objet, elles sont une source d'information fort précieuse.
Selon l'ampleur du PM objet et selon les ressources disponibles, l'équipe pourra être
formée d'un chef de projet, d'un ou de plusieurs analystes, du demandeur et d'un
groupe de représentants des utilisateurs.

Livrable(s) attendu(s) :
• Liste des membres de l'équipe de diagnostic avec leurs coordonnées et leurs
responsabilités.
Acteur(s) responsable(s) :
• Analyste.
Autre(s) intervenant(s) :
• Demandeur.

4.6.1.2 Choisir les outils de travail

Poser le diagnostic consiste essentiellement à recueillir de l'information et la mettre

en forme en construisant des modèles du PM objet, à préparer la documentation de

114 de 273
ces modèles et à utiliser modèles et documentation pour identifier les problèmes,
leurs causes et déterminer des éléments de solution qui seront à la base de la
construction de nouveaux modèles pour le nouveau PM. Les outils et techniques de
travail de l'équipe du diagnostic seront donc les instruments qui faciliteront
l'accomplissement des ces tâches.
Comme décrit précédemment (cf. 4.5.2), il existe quatre principaux outils de collecte
de l'information : L'entrevue, le questionnaire, l'observation, le sondage et la
documentation disponible. Tous ces outils n'auront pas à être utilisés dans toutes les
situations. Les questionnaires, par exemple, sont utiles pour obtenir des
renseignements précis sur le PM objet ou sur son environnement, et cela auprès d'un
grand nombre de personnes. L'observation sert parfois à voir comment les
utilisateurs (ou certains logiciels) exécutent leurs tâches. Quant aux entrevues et la
documentation, ce sont des outils à utiliser dans toutes les situations.
On doit non seulement déterminer quels outils de collecte d'information seront
utilisés, mais également quelles seront les sources d'information. Celles utilisées lors
de l'étude préliminaire devront être consultées aussi lors de la phase de diagnostic. À
la différence qu'à ce niveau de l'étude, les questions posées lors de l'entrevue
devront être plus précises car l'équipe de travail et particulièrement l'analyste doit
être au courant de chaque détail du PM objet.
Que l'équipe soit constituée d'un seul analyste ou qu'elle comporte plusieurs
analystes, des utilisateurs, des gestionnaires, etc. le travail à accomplir, de même
que les rôles et les responsabilités de chacun devront être déterminés avec soin. Ici
encore, l'information recueillie lors de l'étude préliminaire est fort précieuse
puisqu'elle décrit les grandes composantes du PM objet auxquelles le chargé de
projet (ou l'analyste) se référera pour découper le travail de sorte que chaque
personne sache quoi faire et quels sont son rôle et ses responsabilités au sein de
l'équipe.
Livrable(s) attendu(s) :
• Liste des membres de l'équipe de diagnostic avec leurs rôles et leurs
responsabilités;
• Choix des outils de collecte de l'information.
Acteur(s) responsable(s) :
• Chargé de projet (ou l'analyste).
115 de 273
 Autre(s) intervenant(s) :
• Demandeur.

4.6.1.3 Dresser un échéancier

Le requérant ayant formulé la demande de modélisation a certainement des

exigences quant au moment où l'étude devrait être achevée. Le chargé de projet (ou
l'analyste) devra s'assurer donc de bien évaluer le temps nécessaire à chacune des
étapes à accomplir et de respecter les échéances établies. Si l'expérience est un
atout dans l'établissement des échéanciers, elle n'est parfois pas suffisante. Certains
aléas peuvent survenir à tout moment et peuvent par conséquent prolonger la durée
de l'étude. Sans être la panacée à tous les problèmes d'échéances, certains outils
(ne faisant pas partie de ce mémoire) permettent soit de mieux estimer le temps
nécessaire, soit d'aider à une meilleure coordination des taches en tenant compte
des préséances, soit de pointer les taches critiques ou de maîtriser efficacement le
déroulement d'un projet. Parmi ces outils, on retrouve les réseaux d'ordonnancement
de type PERT et les diagrammes de synchronisation de type GANTT.

Livrable(s) attendu(s) :
• Échéancier des travaux à réaliser
Acteur(s) responsable(s) :
• Chargé de projet (ou l'analyste).
Autre(s) intervenant(s) :
• Demandeur.

Une fois la planification du diagnostic réalisée et validée par les décideurs,

notamment par le demandeur, nous pouvons passer à l'étape d'analyse de
l'environnement du PM objet afin de le situer par rapport à son environnement et de
connaître l'impact de l'un sur l'autre.

116 de 273
4.6.2 Analyser l'environnement

Un processus métier n'évolue pas dans un vase clos. Il est influencé par de
nombreux facteurs externes et il a aussi un impact sur d'autres facteurs qui
composent son environnement. Pour poser le diagnostic, on doit s'efforcer d'acquérir
une connaissance approfondie sur cet environnement afin d'évaluer le degré de
concordance entre le PM objet et les contraintes de l'environnement. Cette
connaissance sera très utile ultérieurement lors de l'activité de conception du
nouveau PM. De plus, l'information recueillie pourra être utile pour déterminer les
principaux problèmes auxquels aura à faire face l'équipe de travail, de même que
pour prévoir les impacts que pourra avoir un nouveau PM. L'étude préliminaire a déjà
permis de recueillir certains éléments d'information sur l'environnement, notamment
lors de la définition de la frontière du PM objet (cf. 4.5.5). De façon générale, ces
éléments ne sont pas suffisants et la recherche devra se poursuivre. Cette recherche
visera deux des plus grandes dimensions de l'environnement, à savoir la dimension
organisationnelle et la dimension technique.
Au niveau de la dimension organisationnelle de l'environnement, l'analyste doit se
familiariser (ou au mieux, être familier) avec le secteur d'activité de l'UO (Unité
Organisationnelle) propriétaire du PM objet, les principales lois auxquelles est
soumise cette UO et les relations formelles ou informelles avec les principaux
services visés par le PM objet. Si l'importance de la connaissance (ou la
familiarisation avec) du secteur d'activité est évidente pour mener à bien l'étude, la
connaissance des lois est une source précieuse pour identifier les contraintes
environnementales que doit respecter le futur PM. Quant à la connaissances de
relations formelles et informelles entre le PM objet et divers services (ou autres PM)
de l'UO, elle permettra d'une part, de compléter la liste des échanges entre le PM
objet et les acteurs externes; liste entamée lors de la modélisation du contexte (cf.
4.5.6) et d'autre part, cette connaissance servira ultérieurement à concevoir un
nouveau PM qui réponde aux besoins et exigences de l'UO.
Au niveau de la dimension technique, l'objectif est de collecter des renseignements
sur les tendances technologiques de l'UO, sur les composantes actuellement
automatisées du PM objet, s'il y en a, sur l'usage qui en est fait et sur les

117 de 273
 technologies utilisées. Cet aspect a deux utilités : d'une part, il renseigne sur la
culture informatique de l'UO en vue d'une future implantation d'un PM cible
(automatisé) et d'autre part, il recèle une précieuse information sur les logiciels
utilisés (parties déjà automatisées du PM objet) et sur les données confinées dans
des bases de données ou des fichiers.

Livrable(s) attendu(s) :
• Analyse de l'environnement comportant les éléments suivants :
• Liste des lois, règles et politiques auxquelles l'UO organisationnelle est soumise
et qui sont en relation avec le PM objet;
• Liste complétée des messages échangés entre le PM objet et ses acteurs
externes. On peut se limiter à celle déjà établie lors de la modélisation du
contexte (cf. 4.5.6) si elle est jugée complète;
• Tendances technologiques de l'UO à court et moyen termes;
• Liste des parties automatisées du PM objet et technologies utilisées;
• Liste des données confinées (Bases de données, fichiers, etc.) avec une
description sommaire sur le type de données.
Acteur(s) responsable(s) :
• Analyste.
Autre(s) intervenant(s) :
• Personnes connaissant bien l'UO;
• Personnes connaissant bien le PM objet;
• Développeurs connaissant les parties automatisées du PM objet;
• Personne connaissant bien l'infrastructure technologique de l'UO.

4.6.3 Collecter l'information sur le PM objet

L'étude préliminaire a déjà permis de recueillir un certain nombre d'informations sur le

PM objet. En particulier, on disposera, à ce stade de l'étude, de la définition de la
frontière du PM objet (cf. Tableau 28), de la liste des acteurs externes et des
messages échangés (cf. Tableau 30) et du diagramme de contexte (cf. Figure 19).
Ces informations, quoique enrichies lors de l'étape de l'analyse de l'environnement

118 de 273
 (cf. 4.6.2) ne sont pourtant pas suffisantes pour poser le diagnostic. L'équipe de
travail doit poursuivre sa collecte d'information pour améliorer sa compréhension du
PM objet afin d'être en mesure de l'évaluer. La modélisation du PM objet permettra
de formaliser l'information recueillie, de la documenter, de la valider et de s'assurer
que l'équipe de travail et les personnes impliquées ont une compréhension
commune. Les modèles du PM objet serviront par la suite d'outils d'analyse lors du
diagnostic. Cette façon de faire permet non seulement de mieux comprendre ce que
l'on analyse mais évite également des retours en arrière inutiles et coûteux.
Rappelons qu'à ce niveau de l'étude, le PM objet n 'est plus considéré comme une
boite noire vue seulement de l'extérieur, mais plutôt comme un système ouvert pour
lequel on désire comprendre comment il fonctionne. Pour le PM objet ainsi vu, la
collecte d'information portera sur trois dimensions que nous avons jugées
essentielles : Ses composantes, ses performances et ses problèmes. Ces
dimensions sont présentées plus loin. Les responsables du diagnostic devront cerner
adéquatement ces trois dimensions afin d'être en mesure de bien mener le
diagnostic.
C'est encore une fois par le biais des entrevues, de l'analyse de la documentation et
éventuellement de l'observation ou de questionnaires qu'on procède à la collecte de
l'information sur le PM objet.

4.6.4 Collecter l'information sur les composantes

Le Tableau 32 (qui reprend en partie le Tableau 28) rappelle ce que sont les
composantes essentielles d'un PM. C'est donc sur ces composantes qu'on
recueillera des données afin de compléter l'information déjà accumulée. La
documentation produite lors de l'étude préliminaire constitue un bon point de départ.
L'effort de collecte de l'information sur les composantes du PM objet est bien souvent
mis sur la compréhension des activités qui le composent, sur l'énumération des
acteurs (internes) qui réalisent ces activités ou y sont impliqués (notons que les
acteurs externes au PM ont été identifiés lors de la modélisation du contexte) en
décrivant leurs rôles et responsabilités ainsi que les messages échangés. La collecte
d'information sur les composantes sera aussi orientée vers la compréhension de la

119 de 273
logique métier (traitements effectués). Nous rappelons, encore une fois, que le PM
objet est vu, à ce stade de l'étude, non plus comme une boite noire mais comme un
système « regardé » de l'intérieur. De ce fait, l'analyste (ou le groupe chargé de cette
étape) doit identifier les acteurs que nous avons désignés par « acteurs internes »,
les messages échangés de ces derniers avec le PM objet et les activités (en termes
de fonctions ou services rendus) du PM objet. Cette étape peut aussi être l'occasion
pour mettre à jour le diagramme de contexte (cf. 4.5.6) si la collecte d'information sur
le PM objet conduit à l'identification de nouveaux acteurs externes et/ou de nouveaux
messages échangés entre ces acteurs et le PM objet.
La première source d'information sur les composantes d'un PM est sans doute les
documents servant comme supports aux messages échangés (ou accompagnant ces
derniers) entre les acteurs et le PM : par exemple, le bon de commande ou la facture,
les procédures administratives et la description des tâches sont parmi les principaux
éléments de documentation. Des sources d'information complémentaires,
principalement les entrevues avec des gestionnaires et des personnes connaissant
bien le PM objet ainsi que l'observation du déroulement de certaines activités,
notamment celles qui sont les moins documentées, sont évidemment nécessaires.

La démarche proposée pour réaliser cette étape est la suivante :

• Identifier les acteurs internes selon le même principe que celui décrit dans la
section 4.5.6;
• Identifier les messages échangés selon le même principe que celui décrit dans la
section 4.5.6;
• Identifier les activités du PM objet en termes de fonctions ou services rendus aux
acteurs qu'ils soient internes ou externes.

L'information recueillie à ce niveau prend souvent la forme de listes, de tableaux et

de brèves descriptions : Liste des acteurs internes, liste des messages échangés,
liste des activités. Toute l'information ainsi collectée sera organisée et formalisée plus
tard, sous formes de modèles qui seront décrits dans l'étape de modélisation du PM
objet (cf. 4.6.7).

120 de 273
 Composante Description

Acteurs effectuant les tâches au sein du processus

Acteurs effectuant les
métier objet ou y sont impliqués tels que Commis aux
activités du PM objet
commandes, commis à la facturation, livreur, etc.
Liste des messages échangés entre les acteurs et le
PM objet. On retrouve souvent, dans la littérature, les
Messages
termes input/output ou entrée/sortie pour désigner les
messages envoyé/reçu.
• Description sommaire de l'activité générale du
processus métier objet;
Activités
• Énumération des activités composant l'activité
générale.
Tableau 32 Les composantes du processus métier objet

Livrable(s) attendu(s) :
• Information sur le PM objet comportant les éléments suivants :
o Liste des acteurs internes et des messages échangés (similaire au Tableau
30);
o Liste des activités composant le PM objet avec une description la plus
détaillée possible sur chaque activité.
Acteur(s) responsable(s) :
• Analyste.
Autre(s) intervenants) :
• Personnes connaissant bien le PM objet;
• Employés impliqués dans les activités car ils permettent de comprendre quelles
tâches sont effectuées, comment elles le sont et pourquoi c'est ainsi;
• Développeurs connaissant les parties automatisées du PM objet.

4.6.5 Collecter l'information sur les performances

L'objectif de cette activité est de collecter des données sur les performances du PM
objet. Ces données permettront de l'évaluer par rapport aux objectifs énoncés lors de
l'étude préliminaire. Cependant, il se peut que cette collecte d'informations puisse
révéler de nouveaux objectifs qui n'avaient pas encore été mentionnés et c'est pour
cela que nous insistons sur le fait que toutes les étapes menées par l'équipe de
121 de 273
travail sont itératives. Il est parfois plus utile de revenir sur certains aspects dans le
but de les préciser davantage ou de les modifier plus tard.
En ce qui concerne les performances, on dit souvent qu'un PM est performant s'il
répond aux besoins des acteurs (internes ou externes) et ce dans le meilleur délai, au
meilleur coût, c'est à dire de manière efficace et efficiente. Les deux termes efficacité
et efficience sont souvent confondus. Pour lever cette ambiguïté, nous nous référons
à la définition fournie par le Grand dictionnaire terminologique [68] : « ... l'efficacité
est le rapport entre les résultats obtenus et les cibles déterminées. Il ne faut pas
confondre l'efficacité avec l'efficience qui est le rapport entre les résultats obtenus et
les ressources utilisées pour les atteindre. Ainsi, une méthode de travail est efficace
si elle permet de réaliser entièrement l'objectif initial et elle est efficiente si un
minimum de ressources sont utilisées pour l'atteinte de cet objectif. »
Mais quels critères d'efficacité ou d'efficience peut-on utiliser ?. Il existe certainement
plusieurs critères et plusieurs techniques d'évaluation des performances
(Benchmarking, simulation de processus, comparaison avec d'autres organisations,
etc.). Notre objectif est de simplifier l'approche car nous avons jugé qu'il est inutile de
proposer une technique complexe ou une multitude de critères qui seraient soient
difficiles à appliquer, par manque de temps ou de ressources ou tout simplement, ne
seront jamais utilisés. Nous présentons dans le Tableau 33 (critères d'efficacité) et le
Tableau 34 (critères d'efficience) ceux que nous avons retenus. Notre choix est
justifié par la facilité de leur utilisation et qu'il n'est pas nécessaire d'être un expert en
évaluation des performances pour les cerner. Mais tout cela n'empêche pas l'équipe
de travail d'en rajouter d'autres pour enrichir leur étude.

Quels que soient les critères adoptés, il n'est pas nécessaire que le PM objet atteigne
la cote maximale pour ces critères. C'est avec les différents intervenants, notamment
le demandeur et les principaux gestionnaires qu'il faudra déterminer les besoins et
les attentes en ce qui a trait à ces critères. Il sera non seulement nécessaire
d'énoncer les critères qui constituent les objectifs du PM objet, mais également de les
quantifier, c'est à dire spécifier la valeur souhaitée pour chacun des critères. Ainsi un
acteur pourrait souhaiter obtenir l'information sur la solvabilité d'un client le jour
même de sa demande; un autre pourrait émettre le désir de faire traiter 100
commandes par jour, etc.

122 de 273
 Encore une fois, l'entrevue, l'observation et la documentation existante au sein de
l'UO sont d'importantes sources d'informations. À titre indicatif, la consultation des
registres des commandes et des livraisons pourrait déterminer le délai moyen actuel
de traitement d'une commande. L'entrevue d'un gestionnaire pourrait déterminer la
valeur cible pour un tel critère. Et ainsi de suite. L'objectif est de renseigner, avec le
plus de précision possible, le Tableau 33 et le Tableau 34.

Description
d'évaluation
1 Q.
Rendre la sortie (output)
Disponibilité au moment Délai de facturation d'un
disponible au moment
désiré client.
opportun.
Conformité par rapport aux
Conformité aux Taux de sorties non
normes, aux règles, consignes,
spécifications conformes.
etc.
Taux d'erreur.
Fiabilité Exactitude et précision
Nombre de plaintes.
La rapidité avec laquelle une Temps écoulé entre une
Rapidité du service
activité produit un service. commande et sa livraison.
Taux de commandes
incomplètes livrées en
La sortie (output) est livrée en plusieurs livraisons (ce qui
Complétude
entier ou en plusieurs lots. génère des frais
supplémentaires, par
exemple)
Tableau 33 Les critères d'efficacité des sorties (outputs) d'un PM

123 de 273

Durée de traitement d'une
Temps réel de traitement
transaction.
Nombre de transactions
Nombre de transactions
exécutées par un acteur.
Durée d'attente d'une
Temps d'attente transaction avant d'être
traitée.
Tableau 34 Les critères d'efficience d'un PM
:
d'évaluation
Délai de traitement d'une
commande-client.
Nombre de commandes
traitées par employé/jour.
Délai avant que
l'information sur la
solvabilité d'un client soit
fournie.

4.6.6 Collecter l'information sur les problèmes

Au cours de l'étude préliminaire, l'équipe d'analyse s'est déjà intéressée à la

perception qu'ont les divers intervenants sur les problèmes du PM objet, notamment
lors de la clarification de la demande où ils auraient pris en compte la vision générale
du demandeur sur les problèmes. Tout au long du diagnostic, cette activité doit être
poursuivie plus à fond avec les différents intervenants affectés par ces problèmes. On
doit prendre en compte tous les problèmes identifiés et leurs causes probables que
ce soit au cours des entrevues, de l'étude des documents existants ou de la
modélisation. Il ne s'agit pas à ce niveau de trouver des solutions aux problèmes
énoncés mais simplement de les répertorier et de les documenter. Les solutions
seront proposées lors de la phase de l'analyse (cf. section 4.7).
L'activité de collecte de l'information sur les problèmes et leurs causes devra être
menée avec soin car elle sera très utile, lors de la phase d'analyse, pour l'élaboration
des nouveaux modèles du PM objet. Pour ce faire, nous proposons d'utiliser une
fiche semblable à celle décrite dans le Tableau 35 ci-après, qui permet de prendre
note non seulement des problèmes identifiés mais aussi de leurs causes probables et
de la source d'information ayant permis de les définir.

124 de 273
Fiche 04 Liste des problèmes et causes probables Date: 2004-10-24
Direction de la
Unité
gestion de la Code unité : U01
organisationnelle
production
Domaine Commercial Code domaine : U01_D01
Gestion des
Processus métier Code processus : UO01_D01_P02
commandes

Énoncé du problème Source Cause probable

•

Tableau 35 Liste des problèmes et leurs causes probables

Livrable(s) attendu(s) :
• Liste des problèmes et leurs causes probables.
Acteur(s) responsable(s) :
• Analyste.
Autre(s) intervenant(s) :
• Demandeur;
• Clients du PM objet;
• Employés fortement impliqués dans les activités du PM objet;
• Développeurs connaissant les parties automatisées du PM objet.

125 de 273
4.6.7 Modéliser le PM objet

L'objectif de cette étape est de décrire Le PM objet au moyen de fiches et d'outils

graphiques afin de mieux en comprendre le fonctionnement et d'être à même de
poser le diagnostic à son sujet. Les modèles résument en quelque sorte toute
l'information collectée. Rappelons que comme toutes les activités décrites dans ce
mémoire, la collecte d'information et la modélisation se font conjointement et sont
itératives : les modèles ont été élaborés ou du moins abordés, tout au long de la
collecte de l'information sous formes de fiches synthétiques (cf. Fiche 01 et FicheO2,
par exemple) ou de graphiques tels que le modèle de contexte. Ces modèles doivent
être validés au fur et à mesure auprès des personnes impliquées et révisés de façon
à représenter la réalité. Ils constituent un bon outil de travail permettant à l'équipe de
travail (chargé de projet, analyste, gestionnaires, etc.) d'acquérir une compréhension
commune.
Dans le cadre de cette étape, une illustration de la modélisation du PM objet sera
faite au moyen de l'exemple du PM objet « Gestion des commandes » présenté à la
section 4.5.6, pour lequel nous avons imaginé que la poursuite du recueil
d'information selon la démarche proposée à la section 4.6.4, nous a fourni les
compléments d'information suivants. Toute commande envoyée par un client est
enregistrée par un commis aux commandes, dans un registre de commande en
mentionnant le nom du client, son numéro de téléphone et son adresse. Ensuite, il
envoie une copie de la commande au PM « Gestion des clients ». Ce denier informe
le commis aux commandes de la solvabilité du client. Si le client n'est pas solvable,
un avis de refus lui est adressé. Sinon, le commis aux commandes calcule le total de
la commande, détermine la date de livraison et envoie la commande à l'agent qui
prépare les livraisons. Celui-ci regroupe les éléments identiques d'une commande,
met à jour le registre du stock et envoie une copie de la commande au livreur. Ce
dernier sélectionne la commande à livrer et procède à la livraison au client. À la
livraison, il fait signer par le client un bon de livraison qu'il remet au commis à la
facturation. Ce dernier compare la commande avec les produits réellement livrés et
produit la facture qu'il envoie au client et reçoit en échange le payement. Si un produit
n'est pas disponible, le commis aux achats est avisé par l'agent qui prépare les

126 de 273
livraisons et procède alors à une commande auprès d'un fournisseur. Le fournisseur
envoie la marchandise accompagnée d'un bon de livraison et reçoit en échange le
payement. Une copie de toute commande reçue de la part d'un client solvable est
envoyée au PM « Gestion des archives » qui gère, entre autres, l'historique des
commandes.

Lors de la collecte d'information sur le PM objet (cf. 4.6.3), l'analyste a préparé la liste
des acteurs et des messages échangés et la liste des activités composant le PM
objet. À partir de ces éléments, nous pouvons commencer la modélisation
proprement dite du PM objet. Pour ce faire, nous devons tenir compte de la stratégie
de modélisation adoptée, notamment du formalisme à utiliser; et il en existe plusieurs
[57]. Le plus fréquemment utilisé est sans doute celui proposé par l'ANSI, un
organisme américain de normalisation (American National Standard Institute). Les
principaux symboles ANSI servant à la modélisation d'un processus sont présentés à
la Figure 21

127 de 273
 Activité de transformation d'un input Représente le début ou la fin
Activité en output effectuée entièrement d'un processus.
manuelle manuellement.

Entreposage: fichier, base de

Décision - manuelle ou entièrement données, registre, matières
automatisée. Une activité décision- premières, etc.
nelle aboutira à deux options de
traitement (transformation) possibles.

Connecteur: est utilisé lorsque le

Inspection. Activité qui consiste à
vérifier la qualité d'un output. II peut
par exemple représenter l'approba-
tion du contenu d'un document et
l'apposition d'une signature.
modèle requiert l'utilisation de plus
Connecteur d'une page. En y inscrivant la lettre
ou le chiffre correspondant, on peut
indiquer au lecteur - ou au logiciel,
le cas échéant - de quelle façon sont
reliées les activités situées sur des
pages différentes.

Indique que l'output d'une activité

Entreposage informatique. Indique
est un document.

t
Entreposage / qu'un support informatique est utilisé
Informatique \ pour entreposer des données, des
documents.

Indique un délai, donc une file

d'attente. Est utilisé lorsqu'un input Activité de transformation d'un input
est en attente de traitement, soit Activité en output avec l'interaction entre
parce que les traitements sont effec- à interface l'utilisateur et l'ordinateur.
tués par lots, soit parce que l'activité humain-machine
à laquelle il est destiné n'a pas ter-
miné le traitement de l'input précédent.
Activité de transformation d'un input
Activité en output entièrement automatisée
Représente le mouvement entre complètement (sans intervention humaine).
les activités. informatisée

Figure 21 Symboles ANSI pour représenter les processus [57]

D'autres formalismes existent, notamment celui proposé par Jacobson (cf. 4.5.6) et
celui proposé par Rational/Rose (Tableau 29). Dans la suite de ce mémoire, nous
proposons d'utiliser un formalisme combinant celui de l'ANSI et celui de
Rational/Rose. Les deux formalismes permettent de représenter n'importe quel
modèle et n'importe quel diagramme. Cependant, celui de l'ANSI a l'avantage de
montrer clairement sur un diagramme les notions d'activité manuelle, d'activité
informatisée, d'activité d'attente et de connecteur entre activités; tandis que celui de
Rational/Rose précise clairement la distinction entre acteur interne et acteur externe,
entre acteur humain et celui qui ne l'est pas ainsi que les concepts forts utiles de
diagrammes (de contexte, de collaboration, de séquences, etc.) qui montrent les
aspects statiques et dynamiques des systèmes étudiés.
Pour la modélisation du PM objet, nous proposons de la faire en deux temps.
D'abord, un modèle global du PM objet et de ses sous-processus (cf. Figure 22) puis

128 de 273
 un modèle détaillé de chacun des sous-processus (cf. Figure 23 et Figure 24). En
effet et selon l'American Productivity & Quality Center [69], il existe dans toute
organisation une hiérarchie de PM. Chaque PM peut être considéré comme un
macro-processus formé de sous-processus qui sont reliés entre eux de façon logique,
visant ainsi à réaliser l'objectif du macro-processus. Ce découpage en sous-
processus permet de diminuer la complexité de l'analyse. Dans ce mémoire, le
macro-processus sera désigné par les termes « modèle global ».
La démarche proposée lors de cette étape, s'articule autour des activités suivantes :
• Construire le modèle global du PM objet;
• Construire les modèles des sous-processus.

4.6.8 Construire le modèle global du PM objet

L'objectif de ce modèle est de montrer l'enchaînement des activités au sein du PM

objet vu sous un aspect macroscopique sans trop de détails, ainsi que les échanges
de ce dernier, en termes d'entrées et de sorties (inputs/outputs), avec son
environnement. Pour élaborer ce modèle, l'analyste se base sur les résultats de
l'étude préliminaire (liste des acteurs externes, liste des messages, diagramme de
contexte) et sur le complément d'informations résultant de l'activité de collecte de
l'information sur le PM objet (cf. 4.6.3), notamment la liste des acteurs internes, les
messages échangés et la liste des activités du PM objet. À l'aide des ces éléments et
du formalisme adopté, le modèle global devrait avoir une forme similaire à celui
proposé, à titre d'exemple, dans la Figure 22.

Livrable(s) attendu(s) :
• Modèle global du PM objet
Acteur(s) responsable(s) :
• Analyste.
Autre(s) intervenant(s) :
• Demandeur;
• Clients du PM objet;
• Employés fortement impliqués dans les activités du PM objet;

129 de 273
Développeurs.

:
• • • • : • • • •• •

Encluliwnwitfit produit! du PM objet

Figure 22 Modèle global du PM objet « Gestion des commandes »

130 de 273
4.6.9 Construire les modèles des sous-processus du PM objet

Une fois le modèle global soumis aux divers intervenants et validé, nous procédons à
l'élaboration des modèles des sous-processus composant le PM objet. À titre
d'illustration, nous nous limiterons, dans ce mémoire, aux deux premiers sous-
processus, à savoir 1-Prendre la commande-client et 2-Préparer la livraison.
Les modèles de ces deux sous-processus sont schématisés dans la Figure 23 et la
Figure 24.

Livrable(s) attendu(s) :
• Modèles des sous-processus du PM objet
Acteur(s) responsable(s) :
• Analyste.
Autre(s) intervenant(s) :
• Demandeur;
• Clients du PM objet;
• Employés fortement impliqués dans les activités du PM objet;
• Développeurs.

C ode acteur ou PM Bnchalnamanta et produits du H i u i - p r o u i u i i i 1-Prorida commanda-client

Figure 23 Modèle sous-processus « Prendre la commande-client »

131 de 273
Figure 24 Modèle sous-processus « Préparer la livraison »

132 de 273
4.6.10 Établir le diagnostic

Cette étape a pour but d'analyser l'information sur le PM objet qui a préalablement
été recueillie puis synthétisée dans les modèles (Figure 22, Figure 23 et Figure 24),
les fiches d'identification des problèmes (Tableau 35) et les tableaux des critères
d'efficacité (Tableau 33) et d'efficience (Tableau 34).
Selon le dictionnaire Larousse (1993) : « Le diagnostic est l'identification d'une
maladie par ses symptômes ». C'est tout à fait ce en quoi consiste le diagnostic qui
est présenté ici. Il s'agit en effet de déterminer quels sont les dysfonctionnements du
PM objet et leurs impacts, en se basant sur les symptômes (problèmes). De la même
façon que le médecin procède à certains prélèvements et autres examens spéciaux
afin de mieux poser son diagnostic, l'analyste aura examiné des documents, consulté
des intervenants et procédé à des observations. Les modèles du PM objet et la fiche
de documentation des problèmes constituent déjà un premier pas dans la pose du
diagnostic, puisqu'ils auront permis d'identifier certains problèmes et de déterminer
quelques éléments de causalité. Dans la majorité des situations, les causes des
problèmes sont mixtes. Certaines sont directement liées au PM objet, les autres
relèvent de multiples domaines, aussi bien de la gestion de personnel que de la
gestion des opérations par exemple.
Établir le diagnostic est donc une tâche complexe qui requiert une approche
rigoureuse. L'analyste (ou l'équipe du diagnostic) devra mettre à contribution tous les
outils qui peuvent lui être utiles pour accomplir cette tâche efficacement. Les modèles
du PM objet constituent un premier type d'outil qui permet l'analyse en vue du
diagnostic. La fiche d'identification des problèmes est un bon outil de documentation,
mais aussi d'identification des causes probables d'un problème.
Nous insistons dans cette étape sur les problèmes car ils sont au cœur de l'activité de
diagnostic. D'une part, comme nous en avons discuté au chapitre 2, ils sont à l'origine
du projet de modélisation des processus métiers. D'autre part, les activités de collecte
de l'information et de modélisation avaient comme important objectif de mener à
l'identification des problèmes du PM objet.

133 de 273
 Nous proposons, dans la présente étape, de reprendre la fiche des problèmes établie
auparavant (cf. section 4.6.6) et de la compléter. Le but visé est d'aboutir à une fiche
mise à jour. Une fiche qui recense l'ensemble des problèmes identifiés, les sources
ayant détecté ces problèmes et les causes probables. Nous pouvons nous limiter au
contenu de la fiche établie dans la section 4.6.6 s'il est jugé suffisant. Cependant, il
sera non seulement important de définir les problèmes, mais aussi d'en évaluer les
impacts (insatisfaction de la clientèle, coût élevé, taux d'erreur, perte de revenus,
etc.). L'évaluation des impacts d'un problème remplit deux objectifs. D'une part, elle
permet de déterminer si le problème est suffisamment important pour qu'on lui
accorde une attention particulière, et d'autre part, d'établir par la suite un ordre de
priorité. En effet, on souhaitera sans doute s'attaquer d'abord aux problèmes ayant
des impacts importants plutôt qu'à ceux dont les impacts sont négligeables.
À cet effet, nous proposons de construire une fiche semblable à celle présentée dans
le Tableau 36, ci-après.
Fiche 05 Liste des problèmes, causes et impacts Date: 2005-02-10
Unité Direction de la
gestion de la Code unité : U01
organisationnelle
production
Domaine Commercial Code domaine : U01_D01

Gestion des
Processus métier Code processus : UO01_D01_P02
commandes
Énoncé du problème Cause probable Impact

Tableau 36 Liste des problèmes, leurs causes probables et leurs impacts.

134 de 273
 Livrable(s) attendu(s) :
• Liste des problèmes, leurs causes probables et leurs impacts.
Acteur(s) responsable(s) :
• Analyste.
Autre(s) intervenant(s) :
• Demandeur;
• Clients du PM objet;
• Employés fortement impliqués dans les activités du PM objet.

4.6.11 Préparer et présenter le rapport du diagnostic

Le rapport de la phase du diagnostic est un document important puisqu'il permet aux

différents intervenants (décideurs, utilisateurs, analystes, etc.) d'avoir une vision sur
l'état du processus objet, notamment sur les problèmes qui rendent le processus
moins efficient et/ou moins efficace ainsi que sur les causes et les impacts de ces
problèmes. Ce rapport servira de base à la décision de poursuivre ou d'abandonner
la conception du nouveau processus métier (PM cible). Nous conseillons d'éviter, lors
de la rédaction de ce rapport, d'engloutir le lecteur dans une foule de détails et de se
limiter à l'essentiel de ce qui pourrait éclairer sa décision. En effet, le lecteur (ou l'être
humain en général) cherche prioritairement à savoir ce qui ne marche pas, pourquoi
cela ne marche pas et quels sont les impacts. C'est dans ce but que nous proposons
dans le Tableau 37 un exemple de table de matière pour ce rapport. Les éléments de
documentation rassemblés ou élaborés au cours de la phase de diagnostic ne font
pas partie du rapport du diagnostic comme tels mais devront être mis à la disposition
de ceux qui veulent plus de détails.

135 de 273
 Sommaire
1. Rappel de la demande
• Requérant (Personne ayant formulé la demande);
• Description sommaire du processus métier objet de l'étude;
• Problème(s) identifié(s) par le requérant.
2. Modèles
• Modèle global du PM objet.
• Modèles des sous-processus du PM objet.
3. Information sur les performances
• Les critères d'efficacité utilisés et leur mesure.
• Les critères d'efficience utilisés et leur mesure.
4. Problèmes
• Liste des problèmes, leurs causes probables et leurs impacts.
5. Description des tâches à accomplir pour la suite de l'étude.
6. Recommandations

Tableau 37 Exemple de table des matières pour le rapport du diagnostic

Souvent, les auteurs du rapport du diagnostic en feront une présentation orale au

cours de laquelle les décideurs pourront demander des éclaircissements, émettre des
commentaires et apporter des correctifs. A la suite de la présentation de ce rapport et
de sa validation par le demandeur et les principaux gestionnaires, nous pourrons
débuter la phase d'analyse dont le but principal est la modélisation du nouveau PM.

En résumé, le diagramme de la Figure 25 présente les étapes et les produits de la

phase du diagnostic. Toutes les étapes décrites sont itératives, c'est à dire qu'à
chaque niveau (défini par le numéro de l'étape), il est possible de retourner au niveau
précédent pour complément d'information ou pour actualiser ce dernier en cas
d'omission ou d'apparition de nouveaux éléments qui conduisent à une révision de ce
qui a été conçu auparavant.

136 de 273
 i.l Planifiertediagnostic 3.3 Collecter lïnformallon
3.2 Analyser l'environnement 3.4 Modèllser le PM objet 3.5 Établir le diagnostic
dejeœtant sur le PM objet le rapport du diagnostic

Liste tles membres de l'ê^uipe de diagnosfc

(coordonnées, rôles, responsabilités)
a til(s) choisi(s) pour la collecte S information
Échéancier des travaux à réaliser

Liste des lois, règles et politiques de 1110
Liste complétée des messages échangés entre
le PM et ses acteurs externes
Tendances technologiques de l'UO à court et
moyen ternies
Liste des parties automatisées du PM objet et
Liste des acteurs Internes et des messages •Liste des problèmes, leurs Rapport du diagnostic
échangés Modèles des sous-processus causes probables et leurs
Liste des activités composant le PM objet du PM objet impacts.
Liste des «Itères d'efficacité du PM objet
Liste des critères d'efficience du PM objet
Liste des problèmes et leurs causes

Liste des données confinées (Bases oe

données, fichiers, etc.)

Figure 25 Activités et produits de la phase du diagnostic

137 de 273
4.7. La phase d'analyse

La phase d'analyse a pour but principal de traduire le diagnostic réalisé sous forme
d'objectifs clairement formulés en proposant des solutions visant l'optimisation du
processus objet : « réduire de 30% le temps passé à l'accomplissement de telle partie
du processus », « accélérer d'un jour le délai de livraison", « obtenir rapidement
l'information sur la solvabilité du client», « réduire le nombre d'anomalies de 5% »,
etc.
Les résultats du diagnostic (phase précédente) auront permis de circonscrire les
causes des problèmes identifiés. Il est donc normal d'entreprendre la conception des
modèles du PM cible en cherchant à éliminer ces causes.
La méthode décrite dans ce mémoire décompose la phase d'analyse en quatre
étapes. Après avoir planifié le travail à effectuer, les acteurs de l'analyse proposent
des solutions d'amélioration du PM objet qu'ils soumettent à l'approbation des
décideurs. Ces derniers analysent les solutions proposées et choisissent celle qui
répond le mieux à leurs besoins. La solution choisie fera ensuite l'objet de
modélisation afin de montrer la configuration du PM objet transformé. La phase
d'analyse se termine par la rédaction d'un rapport qui sera présenté aux mandataires
de l'étude et à l'équipe de direction de l'organisation.
Les étapes de cette phase sont itératives. En effet, il se peut qu'à tout moment on se
rende compte qu'il manque certains éléments d'information, que ce soit au sujet des
solutions proposées, de la solution retenue ou des nouveaux modèles du PM objet
transformé. Il se produit même parfois que lors de la présentation du rapport, de
nouveaux éléments apparaissent et que certaines des tâches soient à reprendre.
Bien qu'une telle situation ne soit pas agréable, il est préférable qu'elle survienne au
moment de la présentation des résultats de l'analyse qu'ultérieurement, lors de
l'automatisation proprement dite du PM cible.
Les étapes proposées pour mener cette phase sont :
• Planifier l'analyse;
• Proposer des solutions;
• Élaborer les nouveaux modèles du PM objet;
• Préparer et présenter le rapport d'analyse.

138 de 273
4.7.1 Planifier l'analyse

Avant que ne commence l'activité d'analyse proprement dite, le responsable de la

présente étape doit planifier le travail à effectuer. Ceci consiste, principalement, à
former l'équipe d'analyse, à répartir les rôles et les responsabilités et à élaborer un
échéancier.

4.7.1.1 Former l'équipe

La composition finale de l'équipe dépendra de plusieurs facteurs : l'envergure du PM

objet, la taille de l'organisation, la disponibilité et l'expérience des intervenants
potentiels. Il est essentiel que les personnes engagées dans le PM objet et/ou
l'utilisant jouent un rôle important dans l'étude en cours, puisque ce sont elles qui
auront la responsabilité de s'assurer que les nouvelles façons de faire répondront aux
besoins d'affaires de leur organisation. De plus, comme elles connaissent bien les
tâches qui composent le PM objet, elles sont une source d'information et de validation
des solutions à proposer, fort précieuse. Selon l'ampleur du PM objet et selon les
ressources disponibles, l'équipe pourra être formée d'un chef de projet, d'un ou de
plusieurs analystes, du demandeur et d'un groupe de représentants des utilisateurs.
Pour des raisons d'efficacité, nous proposons de maintenir la même équipe que celle
qui a mené la phase du diagnostic car elle a acquis une bonne connaissance des
problèmes et de leurs causes; ce qui lui a donné certainement une bonne idée sur les
solutions envisageables.

Livrable(s) attendu(s) :
• Liste des membres de l'équipe d'analyse avec leurs coordonnées et leurs
responsabilités.
Acteur(s) responsable(s) :
• Analyste.
Autre(s) intervenant(s) :
• Demandeur.

139 de 273
4.7.1.2 Dresser un échéancier

Le requérant ayant formulé la demande de modélisation a certainement des

exigences quant au moment où l'étude devrait être achevée. Le chargé de projet (ou
l'analyste) devra s'assurer donc de bien évaluer le temps nécessaire à chacune des
étapes à accomplir et de respecter les échéances établies. Si l'expérience est un
atout dans l'établissement des échéanciers, elle n'est parfois pas suffisante. Certains
aléas peuvent survenir à tout moment et peuvent par conséquent prolonger la durée
de l'étude. Sans être la panacée à tous les problèmes d'échéances, certains outils
(ne faisant pas partie de ce mémoire) permettent soit de mieux estimer le temps
nécessaire, soit d'aider à une meilleure coordination des taches en tenant compte
des préséances, soit de pointer les taches critiques ou de maîtriser efficacement le
déroulement d'un projet. Parmi ces outils, on retrouve les réseaux d'ordonnancement
de type PERT et les diagrammes de synchronisation de type GANTT.

Livrable(s) attendu(s) :
• Échéancier des travaux à réaliser
Acteur(s) responsable(s) :
• Chargé de projet (ou l'analyste).
Autre(s) intervenant(s) :
• Demandeur.

Une fois la planification de la phase d'analyse réalisée et validée par les décideurs,
notamment par le demandeur, nous pouvons passer à l'étape de proposition de
solutions visant à résoudre les problèmes énoncés lors de la phase du diagnostic.

4.7.2 Proposer des solutions

L'objectif de cette étape est de proposer des solutions en fonction des objectifs de la
demande décrits dans la section 4.4.2 {Clarifier la demande), des caractéristiques du
PM objet identifiés dans les sections 4.5.4 {Identifier les processus métier), 4.5.5

140 de 273
(Définir la frontière du processus métier objet) et 4.5.6 (Modéiiser le contexte du PM
objet) et du diagnostic établi (cf. section 4.6.10).
Comme c'était le cas lors de l'étude préliminaire et du diagnostic, l'équipe d'analyse
devra garder à l'esprit les objectifs de l'organisation en regard du PM objet à l'étude.
En effet, la phase de diagnostic consistait essentiellement à évaluer les performances
du PM objet pour chacun des objectifs qui avaient été spécifiés lors de l'étude
préliminaire et de savoir pourquoi les objectifs visés étaient partiellement, ou pas du
tout, atteints. À partir de ce diagnostic, la proposition de solutions consiste à
déterminer comment organiser les différentes activités du PM objet afin que ces
objectifs soient atteints. Ces solutions devront se préoccuper autant des aspects liés
à l'improductivité du PM objet que de la qualité des productions du PM cible. En effet,
on souhaitera dans un premier temps proposer un nouveau PM plus productif que le
PM actuel : réduire le nombre d'anomalies de 5%, produire à moindre coût, réduire le
temps d'attente d'une livraison, etc. Mais le PM à concevoir devra aussi contribuer
aux objectifs de qualité, comme la disponibilité d'une sortie (output) au moment voulu,
un bon rapport prix/qualité et la conformité aux spécifications, etc.
Il n'existe pas de solution miracle pour décrire comment obtenir les meilleures
solutions. La créativité et l'esprit d'imagination jouent un rôle important dans cette
étape. Il existe pourtant des techniques génériques, plus ou moins complexes, dont
l'application peut mener à la conception de processus métier améliorés. Certaines
visent essentiellement l'amélioration de la productivité (analyse de la valeur ajoutée,
systématisation des processus, ré-ingénierie des processus, etc.) [[1], [30]]. D'autres
techniques sont plutôt axées sur l'amélioration de la qualité d'un produit ou d'un
service (balisage des processus en analysant les processus d'autres organisations
afin de s'en inspirer, cycle de vie des produits et des services, etc.) [[59], [60]]. Ces
techniques ne font pas l'objet du présent mémoire car notre objectif principal est de
concevoir une méthode simple à utiliser, applicable dans sa totalité, qui couvre
l'ensemble des activités nécessaires à la modélisation des processus métier et ne
nécessitant ni de réadaptions à chaque cas ni une expertise poussée pour être
appliquée.

À cet effet, nous proposons pour la recherche de solutions visant l'amélioration du

PM objet de reprendre le Tableau 36 qui synthétise les problèmes, leurs causes et
leurs impacts et de procéder à l'identification des solutions. De la même manière que
141 de 273
 les problèmes sont étroitement liés aux objectifs, les éléments de solution sont
également liés aux causes des problèmes. Ainsi, si la cause d'un délai de facturation
trop long est due à une facturation manuelle, le premier élément de solution
envisageable sera d'automatiser cette opération. Cependant, l'automatisation n'est
pas toujours la solution idéale pour résoudre tous les problèmes. L'équipe d'analyse
doit également rechercher d'autres solutions sans nécessairement tout
« mécaniser » : II suffit parfois de réorganiser certaines activités, quoique manuelles,
au sein du PM pour éliminer les causes de certains problèmes. On suggère de
rechercher les caractéristiques du PM objet qui, si elles étaient modifiées,
contribueraient à l'amélioration du processus.
À titre d'exemples de caractéristiques, mentionnons les activités redondantes, le
fractionnement des tâches, la saisie de la même information à plusieurs endroits, les
multiples copies d'une facture, etc.
Le résultat de cette étape est un tableau similaire à celui présenté ci-après. Il reprend
le Tableau 36 qui recense les problèmes, leurs causes et leurs impacts et auquel on
ajoute les objectifs du demandeur ainsi que les solutions proposées.
. . . ................,.,,.... ........ Élément de solutions Date : 2005-04-02
Fiche 06
Unité
Direction de la gestion de la
Code unité U01
organisationnello production

Domaine Commercial Code domaine U01_D01

Processus métier Gestion des commandes Code processus UO01_D01_P02

^•oMôlnrr,-, Causes Impacts Solutions

•

• • - • . • ' . .

Réduire le délai de La • Le mode de • Insatisfaction • Prévoir un mode

préparation d'une préparation saisie des des clients. de saisie plus
commande à une de la commandes performant.
journée. commande n'est pas • Manque à
prend 3 jours. efficace gagner car la • Rendre
(formulaire facturation accessible
manuel). est retardée l'information sur
• L'information sur la solvabilité du
la solvabilité du client.
client n'est pas
disponible à
temps.

Tableau 38 Éléments de solutions.

142 de 273
 Une fois les éléments de solutions définis par l'équipe d'analyse, il revient alors à
l'équipe de décision (les gestionnaires de l'UO) d'analyser les choix proposés et de
sélectionner ceux qui constituent, à leurs yeux, la solution à retenir et à base de
laquelle seront conçus, lors de prochaine étape de l'étude, les nouveaux modèles du
PM objet.

Livrable(s) attendu(s) :
• Éléments de solutions.
Acteur(s) responsable(s) :
• Analyste.
Autre(s) intervenant(s) :
• Demandeur;
• Gestionnaires;
• Clients du PM objet;
• Employés fortement impliqués dans les activités du PM objet.

4.7.3 Élaborer les nouveaux modèles du PM objet

L'objectif de cette étape est d'élaborer les nouveaux modèles du PM objet en fonction
de la solution retenue et de distinguer, à travers ces nouveaux modèles, les parties à
automatiser (PM cible) de celles qui ne le seront pas. Ces modèles doivent être
validés au fur et à mesure auprès des personnes impliquées et révisés de façon à
respecter les objectifs de la solution retenue. Ils constituent un bon outil de travail
permettant, d'une part, à l'équipe de travail (chargé de projet, analyste, gestionnaires,
etc.) d'acquérir une compréhension commune sur le PM transformé et d'autre part,
de montrer aux gestionnaires de l'UO, les tâches qui feront l'objet d'une
automatisation ultérieure afin de bénéficier des avantages que procurent les
technologies de l'information.
Les nouveaux modèles présentent les tâches candidates à une automatisation par
rapport à celles qui ne le seront pas; c'est à dire ils montrent la place du système que
l'on propose de développer (PM cible), par rapport au nouveau PM objet [58]. Pour ce
faire, nous devons tenir compte du choix et de la politique du demandeur, notamment

143 de 273
 la solution adoptée, la stratégie de résolution à appliquer, la finalité du PM cible et les
orientations de l'organisation. Il faudrait également compléter cette étape en
fournissant de la documentation décrivant les objectifs du nouveau PM objet, les
objectifs du PM cible (partie à automatiser) ainsi que les bénéfices que pourrait tirer
l'organisation par le transit du PM objet vers le nouveau PM. Ces bénéfices sont
généralement intimement liés aux éléments de la solution adoptée.
Pour la modélisation du nouveau PM objet, nous proposons de la faire en deux
temps, selon le même principe que celui énoncé dans la section 4.6.7 (Modéliser le
PM objet). D'abord, un modèle global du nouveau PM objet et de ses nouveaux sous-
processus puis un modèle détaillé de chacun des nouveaux sous-processus.
Nous fournirons, dans le prochain chapitre, une étude de cas détaillant la présente
étape.

Livrable(s) attendu(s) :
• Objectifs, finalités et bénéfices du nouveau PM objet;
• Modèle global du nouveau PM objet;
• Modèles des nouveaux sous-processus du nouveau PM objet.
Acteur(s) responsable(s) :
• Analyste.
Autre(s) întervenant(s) :
• Demandeur;
• Clients du PM objet;
• Employés fortement impliqués dans les activités du PM objet;
• Développeurs.

4.7.4 Préparer et présenter le rapport d'analyse

Comme tous les rapports énoncés dans ce mémoire, celui de la phase d'analyse est
un document important puisqu'il permet aux différents intervenants (décideurs,
utilisateurs, analystes, etc.) d'avoir une vision sur l'état du processus objet
transformé, notamment sur les solutions préconisées pour remédier aux problèmes
qui rendaient l'ancien processus (PM objet) moins efficient et/ou moins efficace. Ce
rapport permet également de mettre la lumière sur la solution finale adoptée par les

144 de 273
décideurs, sur les objectifs et les finalités du nouveau PM, sur le PM cible (partie
candidate à une automatisation) et également sur les bénéfices escomptés d'une
telle transformation.
Nous conseillons d'éviter, lors de la rédaction de ce rapport, d'engloutir le lecteur
dans une foule de détails et de se limiter à l'essentiel de ce qui pourrait éclairer sa
compréhension. C'est dans ce but que nous proposons dans le Tableau 39 un
exemple de table de matière pour ce rapport. Les éléments de documentation
rassemblés ou élaborés au cours de la phase d'analyse ne font pas partie du rapport
d'analyse comme tel mais devront être mis à la disposition de ceux qui veulent plus
de détails.

Sommaire
1. Rappel de la demande
• Requérant (Personne ayant formulé la demande).
• Description sommaire du processus métier objet de l'étude.
• Problème(s) identifié(s) par le requérant.
2. Éléments de solutions
3. Objectifs et finalités du nouveau PM objet
4. Modèles
• Modèle global du nouveau PM Objet.
• Modèles des nouveaux sous-processus du nouveau PM objet.
5. Bénéfices tirés du nouveau PM objet
6. Recommandations éventuelles

Tableau 39 Exemple de table des matières pour le rapport d'analyse

Souvent, les auteurs du rapport d'analyse en feront une présentation orale au cours
de laquelle les décideurs pourront demander des éclaircissements, émettre des
commentaires et apporter des correctifs. A la suite de la présentation de ce rapport,
une validation par le demandeur et les principaux gestionnaires est nécessaire pour
finaliser l'étude.
En résumé, le diagramme de la Figure 26 présente les étapes et les produits de la
phase d'analyse. Toutes les étapes décrites sont itératives, c'est à dire qu'à chaque
niveau (défini par le numéro de l'étape), il est possible de retourner au niveau
précédent pour complément d'information ou pour actualiser ce dernier en cas

145 de 273
 d'omission ou d'apparition de nouveaux éléments qui conduisent à une révision de ce
qui a été conçu auparavant.

4, ANALYSE

4.4 Elaborer les nouveaux

4.1 Planifier Fanalyse

Liste des membres de l'équipe d'analyse Éléments de solutions Objectifs, finalités et bénéfices du nouveau PU objet Rapport d'analyse
(coordonnées, rôles, responsabilités) Solutions retenues Modèle global du nouveau PU objet
Échéancier des travaux à réaliser Modèles des nouveaux sous-processus

Figure 26 Activités et produits de la phase d'analyse

146 de 273
4.8. Conclusion

Au début de ce chapitre, nous avons évoqué les motivations qui nous ont guidées à
proposer la méthode décrite dans ce mémoire, notamment l'absence sur le marché
d'une méthode applicable dans sa totalité, simple à utiliser, ne nécessitant pas
d'adaptation à chaque cas, n'exigeant pas d'expertise approfondie pour être
maîtrisée et axée sur les processus métier afin de mieux cerner les automatisations
ultérieures et éviter des redondances souvent coûteuses dans les développements
d'applications au sein de la même organisation.
Nous avons montré comment utiliser l'étude préliminaire pour circonscrire le
processus métier sur lequel porte la demande en fonction des objectifs identifiés,
pour cerner les principaux problèmes, pour estimer l'ampleur du projet et des
changements probables et pour développer une compréhension commune de la
structure et de la dynamique des affaires de l'organisation en général et plus
spécifiquement celle du PM objet, sur ses objectifs, sur sa frontière, sur les différents
acteurs qui interagissent avec le PM objet, sur les entrées (inputs) et leurs sources et
sur les sorties (outputs) et leurs destinations.
Dans la phase de diagnostic nous avons fait la synthèse de l'existant en analysant
l'environnement du PM objet afin d'être en mesure d'identifier les contraintes que cet
environnement pose, de même que les opportunités qu'il offre; ensuite nous avons
défini les modèles du PM objet, énuméré les problèmes, leurs causes et leurs
impacts ainsi que les objectifs que devrait atteindre le PM objet une fois transformé et
avons suggéré quelques éléments de solutions qui permettraient d'atteindre ces
objectifs.
Lors de la phase d'analyse nous avons traduit le diagnostic réalisé sous forme
d'objectifs clairement formulés en proposant des solutions visant l'optimisation du
processus objet. La solution retenue par les décideurs est alors utilisée comme base
pour la conception des nouveaux modèles du nouveau PM en identifiant clairement la
partie candidate à une automatisation (PM cible) de celles qui ne le seront pas.
Au niveau de chaque phase et de chaque étape de notre méthode, nous avons
précisé la composition de l'équipe de travail en insistant sur la clarification des rôles
et des responsabilités de chaque membre ainsi que le type de livrables-attendus.

147 de 273
Sauf erreur, nous pouvons affirmer que c'est la première fois qu'une méthode
s'écarte des concepts sophistiqués et complexes des méthodes disponibles
actuellement dans les domaines de la ré-ingénierie des processus; concepts qui
cherchent plutôt une universalité, quasi utopique, pour soit conquérir le plus de
marchés possibles, soit rendre dépendantes les organisations de leur monopole (au
sens expertise), etc. Quoique la démarche proposée puisse s'appliquer non
seulement aux PM mais également dans d'autres contextes tels que la spécification
des besoins et leur modélisation dans un contexte de génie logiciel, notre méthode
vise surtout à se placer en amont des méthodes des ateliers de génie logiciel. Ce
positionnement est à notre avis nécessaire, pour ne pas dire obligatoire, car il permet
d'anticiper et d'éviter une informatisation à l'aveuglette. Le constat est que, dans
plusieurs organisations, plusieurs applications ont été développées de manières
indépendantes alors que leurs objectifs sont quasi similaires et même parfois
identiques. En appliquant la méthode que nous proposons, des coûts et des efforts
inestimables seraient épargnés. C'est ce que nous essayerons de prouver lors de
l'étude de cas, objet du prochain chapitre.

148 de 273
CHAPITRE 5 : ÉTUDE DE CAS

5.1. Introduction

Le but de ce chapitre est d'appliquer la méthode proposée à un cas réel afin de

dévoiler les points forts et les points faibles. Le contexte réel du cas étudié a
l'avantage de mesurer non seulement les apports de la méthode mais également la
réaction des utilisateurs et les difficultés rencontrées lors de son application.
Pour illustrer notre méthode, nous avons choisi l'un des processus métier jugé,
d'après la propriétaire, comme étant le plus problématique au sein de la Direction de
l'adaptation scolaire (DAS). En effet, la réflexion sur la nécessité de modéliser le
processus métier de suivi des projets recherche-action (PRA) et technologie de
l'information et des communication (PTIC) est née de la difficulté à gérer une
multitude de documents comportant une multitude d'informations dont l'analyse et
l'évaluation nécessitent un temps considérable. De plus, avec les restrictions
budgétaires et les départs à la retraite que connaît actuellement l'administration
Québécoise, la gestion de ce PM devient de plus en plus délicate compte tenu du
nombre de ressources insuffisantes dédiées à ce PM.
Ce chapitre est structuré en six sections. La première étant la présente introduction.
La section 2 définit le contexte du cas étudié (PM objet), la mission de l'unité
organisationnelle propriétaire du PM objet et les objectifs généraux du demandeur de
la modélisation.
La section 3 est centrée sur l'initialisation de l'étude dans laquelle sont définies les
ressources affectées à l'étude du cas proposé, les plannings des rencontres et les
échéances des travaux ainsi que la clarification de la demande de modélisation.
La section 4 a pour but de détailler le mandat de l'unité organisationnelle afin de
faciliter l'identification des domaines gérés par cette dernière, des PM qui composent
ces domaines et des frontières du PM objet. Dans cette section, nous procédons
également à l'identification des acteurs et des messages échangés entre ces derniers
et le PM objet ainsi qu'à l'élaboration du diagramme de contexte.

149 de 273
 La section 5 a pour but de cerner davantage le PM objet en analysant son
environnement (lois, règles, politiques, etc.), en identifiant les parties automatisées,
les données confinées (BD, fichiers, etc.) et les tendances technologiques du
Ministère. La collecte d'information a aussi porté sur les trois dimensions énoncées
lors de la description de la méthode proposée (cf. chapitre 4), à savoir ses
composantes, ses performances et ses problèmes. Toute l'information, collectée
dans cette section, a permis d'élaborer les modèles du PM objet et de poser le
diagnostic sur la situation actuelle.
La section 6 a pour but de proposer des solutions aux problèmes rencontrés dans la
gestion actuelle du PM objet. Les solutions retenues ont servi comme bases pour
l'élaboration des nouveaux modèles du nouveau PM objet.

5.2. Contexte du cas étudié

La Politique de l'adaptation scolaire fait ressortir l'importance d'améliorer les

connaissances en regard des interventions à mettre en place pour aider les élèves
handicapés ou les élèves en difficulté à réussir, dans le contexte des nombreux
changements suscités par la réforme de l'éducation.

Le plan d'action qui accompagne cette politique affirme clairement l'engagement du

Ministère de l'Éducation, du Loisir et du Sport à soutenir la recherche et le
développement en adaptation scolaire ainsi qu'à favoriser le renouvellement de
l'expertise, en collaboration avec les partenaires concernés.

La Direction de l'adaptation scolaire (DAS) a pour mission d'orienter et de soutenir le

développement et la mise en œuvre des services éducatifs adaptés aux besoins des
élèves handicapés ou en difficulté d'adaptation et d'apprentissage (EHDAA) pour
l'ensemble des enfants de l'éducation préscolaire et des élèves de l'enseignement
primaire et secondaire prévus dans la Loi sur l'instruction publique.

Dans ce contexte, la DAS a lancé le Programme de soutien à la recherche et au

développement en adaptation scolaire. Le Programme encourage l'innovation et la

150 de 273
mise en œuvre de pratiques visant à mieux intervenir auprès des élèves handicapés
ou des élèves en difficulté. Il se présente en deux volets :

• Projets visant le développement pédagogique et l'acquisition de savoir-faire dans

le domaine des technologies de l'information et de la communication (PTIC);
• Projets de recherche-action (PRA) visant l'expérimentation d'interventions
novatrices en collaboration avec le milieu de la recherche.

Le Programme est conçu pour soutenir financièrement l'élaboration, la réalisation et

l'évaluation de projets novateurs dans le domaine de l'adaptation scolaire. Il a pour
objet de favoriser le développement de nouvelles pratiques d'intervention.

Les objectifs visés par le programme sont les suivants :

• Appuyer le milieu scolaire dans le renouvellement des pratiques éducatives;

• Susciter l'émergence de nouvelles approches ou interventions en adaptation
scolaire;
• Encourager la collaboration entre le milieu scolaire, le milieu de la recherche
(recherche-action) ou les partenaires pour structurer, réaliser et évaluer les
projets.

Compte tenu des sommes disponibles et de la quantité de projets reçus (environ

200/an), ces derniers ne pourront pas tous bénéficier du soutien financier offert dans
le cadre de ce programme. À cet effet, la sélection des projets qui bénéficieront de
soutien financier sera faite en plusieurs étapes.
Dans un premier temps les projets doivent répondre à des critères d'admissibilité
établis par la DAS.
Les projets qui ont passé cette étape seront soumis à un processus de sélection des
projets, par deux comités d'évaluation, constitués de représentants du ministère de
l'Éducation, du Loisir et du Sport et des partenaires concernés (Réseau pour le
développement des compétences par l'intégration des technologies (RÉCIT),
représentants du milieu universitaire et des directions régionales, etc.). Chaque
comité est spécialisé et il a la responsabilité de l'évaluation d'un seul type de projet.
Des dépenses autorisées sont attachées également aux projets approuvés.

151 de 273
 Le cycle annuel de gestion du programme s'étale sur une année.
Le cycle de présentation des projets est le suivant :
• Début septembre : envoi par la DAS du formulaire et de la lettre d'information
avisant les organismes scolaires et les DR sur le début de la réception des
demandes (propositions de projets à réaliser). L'organisme scolaire peut être un
établissement d'enseignement (EE) ou un commission scolaire (CS);
• 15 avril : approbation du projet (EE) proposé par la CS dont dépend l'EE;
• 29 avril : dépôt, à la Direction régionale du Ministère, des projets EE approuvés
par les CS et des projets CS;
• 13 mai : analyse et sélection des projets approuvés par les DR;
• 3 juin : envoi des réponses aux organismes scolaires (CS et EE);
• Septembre à mai : réalisation des projets;
• Fin mai : dépôt des bilans au Ministère.

5.3. La phase d'initialisation de l'étude

La phase d'initialisation a pour but de réunir les conditions de succès de l'étude en

planifiant cette phase, en clarifiant la demande de modélisation, en précisant les
objectifs de modélisation et en définissant la structure de l'équipe de travail ainsi que
les rôles et responsabilité de chacun des membres.
Cette phase comporte 3 étapes :
• Planification de l'initialisation de l'étude et constitution de l'équipe de travail;
• Clarification de la demande;
• Présentation du rapport d'initialisation.

152 de 273
 5.3.1 Planification de l'initialisation de l'étude

Ressources affectées au projet

Unité
Ressource10 Fonction Rnlp Coordonnées
administrative
Volontairement non
R1 DAS Gestionnaire Définir les objectifs fournies dans ce
rapport
Définir les besoins et
Responsable
R2 DAS valider les biens
du programme
livrables
Définir les besoins et
Responsable
R3 DAS valider les biens
du budget
livrables
A.S (Ali Recueillir les besoins
Laval Analyste
Saadi) et modéliser
Tableau 40 Ressources affectées au projet

Planning des rencontres

Date Objet de la rencontre Invités

• • • • • •• . • • . • • • • • • • . • .

Initialisation de l'étude, présentation de la

2005-08-22 demande, énoncé des objectifs et R1,R2,R3,A.S
affectation des ressources
2005-08-23 Recueil des informations sur la demande R1.R2, R3, A.S

2005-08-25 Clarification de la demande R1, R2, R3, A.S

2005-09-06 Présentation du rapport d'initialisation R1.R2, R3, A.S

Tableau 41 Planning des rencontres

Échéancier des travaux

Phase Date début Date fin

Initialisation de l'étude 2005-08-22 2005-09-06

Étude préliminaire 2005-09-06 2005-09-30

10
Les noms et coordonnées des personnes qui ont participé à cette étude ont été masqués pour des raisons
de confidentialité.
153 de 273
Diagnostic de l'existant 2005-10-03 2005-10-30

Analyse 2005-11-07 2005-12-05

Présentation des résultats 2005-12-12 2005-12-12

Tableau 42 Échéancier des travaux

5,3.2 Clarification de la demande

L'objectif principal de la demande est de modéliser le processus métier de suivi des

projets Recherche-action (PRA) et Technologie de l'information et des
communication (PTIC) afin de le cerner davantage et déduire les parties candidates à
une automatisation. Le but escompté est de réduire les efforts actuels et de résoudre
un certain nombre de problèmes. En effet, la gestion actuelle de la majorité des
opérations de ce processus métier sont manuelles; ce qui rend très difficile la tâche
de la DAS d'optimiser son processus d'affaires et de connaître ses liaisons
potentielles avec d'autres processus métier existants. Ces difficultés sont issues
principalement de la masse importante de documents papier (formulaires, lettres,
bilans des projets, etc.) et des nombreux traitements qu'ils doivent subir
manuellement avant d'accepter un projet ou de le refuser.
Lors de la phase de lancement de projets, les formulaires et la démarche à suivre
(lettre d'information) sont envoyés par le Ministère (environ 9600 envois par la poste)
aux différents organismes scolaires (EE et CS) et aux partenaires du Ministère
(cégeps, universités, associations éducatives, etc.). Cette façon de faire ralentit
considérablement le processus de gestion et génère un coût non négligeable; sans
oublier le taux de retours dû soit aux erreurs de frappe soit aux adresses non à jour
(environ 20%).
Lors de la phase d'approbation de projet, il y a également beaucoup d'envois de
documents entre les divers intervenants soit pour compléter la demande, soit pour
demander plus de renseignements sur le projet proposé.
Par ailleurs et suite à l'évaluation des projets, la DAS a beaucoup de difficultés à
compiler les données contenues dans les différents documents reçus et à générer
des rapports de suivi et de synthèse.

154 de 273
 Tout au long du traitement des demandes par la DAS, les responsables des projets
ne sont pas en mesure de connaître précisément l'état de leur demande. Cette
situation est la source de nombreux appels téléphoniques de la part des organismes
scolaires pour connaître l'état du projet qu'ils ont proposé.

Afin de pallier ces difficultés, la DAS souhaite que le nouveau processus métier
puisse contribuer à l'atteinte des objectifs suivants :
• Décentraliser certaines opérations relatives aux projets de manière à éliminer les
formulaires papier;
• Assurer la gestion des documents de différentes natures;
• Assurer le suivi du budget initial et restant des projets;
• Standardiser les informations demandées afin de faciliter l'analyse des
propositions;
• Réduire le délai de traitement des demandes;
• Faciliter la diffusion des informations sur le bilan des projets subventionnés;
• Assurer des opérations de pilotage de système;
• Disposer de tableaux de bords et de statistiques;
• Assurer un accès sécuritaire aux données.

5.4. La phase d'étude préliminaire

L'étude préliminaire consiste à circonscrire le processus métier sur lequel porte la

demande en fonction des objectifs identifiés lors de la phase d'initialisation. Elle est
composée de 7 étapes :
• Planification de l'étude préliminaire;
• Recueil de l'information préliminaire sur le PM objet;
• Identification des domaines;
• Identification des processus métiers;
• Définition de la frontière du PM objet;
• Modélisation du contexte du PM objet;
• Présentation des résultats de l'étude préliminaire.

155 de 273
 5.4.1 Planification de l'étude préliminaire

Le planning qui a été établi, d'un commun accord avec les participants, est le
suivant :

Date début Date fin Responsable Participants

Planification de l'étude
2005-09-06 2005-09-06 A.S R2, R3
préliminaire
Recueil de l'information
2005-09-07 2005-09-12 A.S R2, R3
préliminaire sur le PM objet
Identification des domaines 2005-09-13 2005-09-14 A.S R1.R2, R3
Identification des processus R2, R3, R4,
2005-09-19 2005-09-23 A.S
métiers R5
Définition de la frontière du PM
2005-09-23 2005-09-26 A.S
objet
Modélisation du contexte du PM
2005-09-27 2005-09-28 A.S
objet
Présentation des résultats de
2005-09-30 2005-09-30 A.S R1.R2.R3
l'étude préliminaire
Tableau 43 Planning de l'étude préliminaire

Sources d'information utilisées :

• Gestionnaire de la DAS (R1 );
• Responsable du processus métier (R2);
• Responsable du budget (R3);
• Responsable de la gestion des dossiers des organismes scolaires (R5);
• Responsable de la sécurité informatique (R4);
• Documentation disponible à la DAS.

Méthodes de collecte d'information utilisées :

• Entrevues;
• Lecture de la documentation.

156 de 273
5.4.2 Recueil de l'information préliminaire sur le PM objet

Lors de cette étape, nous avons eu de nombreuses rencontres avec du personnel de

la DAS, notamment la gestionnaire de la DAS, la responsable du programme et le
responsable du budget. Nous avons également consulté la documentation, disponible
au sein de la DAS, qui traite de la DAS, des lois et règles en cours et du processus
métier objet de l'étude. Le résultat est synthétisé dans les sections qui suivent.

5.4.2.1 Mission de la DAS

La Direction de l'adaptation scolaire (DAS) est une unité organisationnelle du

Ministère de l'Éducation, du loisir et du sport (MELS). Son mandat est d'assurer le
développement et la mise en oeuvre des services éducatifs adaptés aux besoins des
élèves handicapés ou en difficulté d'adaptation et d'apprentissage (EHDAA) de
l'enseignement primaire et secondaire prévus dans la Loi sur l'instruction publique.
À cette fin, la DAS :
• Collabore à la définition, à l'évaluation ou à la révision du cadre légal et
réglementaire de l'adaptation scolaire;
• Élabore, évalue et révise les politiques et orientations au regard des services
éducatifs adaptés aux besoins des élèves handicapés ou en difficulté d'adaptation
et d'apprentissage pour l'éducation préscolaire et l'enseignement primaire et
secondaire;
• Conçoit, évalue ou révise les programmes d'études adaptés aux besoins des
élèves handicapés ou en difficulté d'adaptation et d'apprentissage, en assure la
diffusion et la mise en oeuvre;
• Soutient le milieu scolaire dans l'application des lois et règlements, des directives
et des programmes d'études destinés aux élèves handicapés ou en difficulté
d'adaptation et d'apprentissage pour l'éducation préscolaire et l'enseignement
primaire et secondaire;
• Favorise la concertation entre les partenaires visés par les services éducatifs
adaptés aux besoins des élèves handicapés ou en difficulté d'adaptation et
d'apprentissage.
157 de 273
5.4.2.2 Processus métier objet de l'étude

Le programme de Soutien à la Recherche et au Développement en Adaptation

Scolaire (SoReDAS) encourage l'innovation et la mise en œuvre de pratiques visant à
mieux intervenir auprès des élèves handicapés ou des élèves en difficulté. Il se
présente en deux volets : l'un touche plus particulièrement le développement
pédagogique et l'acquisition de savoir-faire dans le domaine des technologies de
l'information et de la communication; l'autre concerne l'expérimentation
d'interventions novatrices en collaboration avec le milieu de la recherche (recherche-
action).

Pourquoi un programme de soutien à la recherche et au développement en

adaptation scolaire?
Le programme est conçu pour soutenir financièrement l'élaboration, la réalisation et
l'évaluation de projets novateurs dans le domaine de l'adaptation scolaire. Il a pour
objet de favoriser le développement de nouvelles pratiques d'intervention. Pour ce
faire, la collaboration du milieu scolaire, du milieu de la recherche ou d'autres
partenaires ayant développé une expertise doit être assurée.

Objectifs visés par le programme :

• Appuyer le milieu scolaire dans le renouvellement des pratiques éducatives;
• Susciter l'émergence de nouvelles approches ou interventions en adaptation
scolaire;
• Encourager la collaboration entre le milieu scolaire et le milieu de la recherche
pour structurer, réaliser et évaluer les projets.

Qu'entend-on par « projets visant le développement pédagogique et l'acquisition de

savoir-faire dans le domaine des technologies de l'information et de la communication
(PTIC) » et par projets de recherche-action (PRA)?

158 de 273
Projets PTIC
II s'agit de projets ayant pour objectif de favoriser le développement des compétences
des élèves handicapés ou en difficulté, tout en visant le développement de l'expertise
du personnel enseignant, professionnel et technique, au regard de l'utilisation des
technologies de l'information et de la communication en classe.
Les projets découlent d'une démarche rigoureuse et structurée qui permet de
déterminer des objectifs, d'évaluer l'atteinte des objectifs et d'indiquer dans quelles
conditions les résultats ont été obtenus.
Ces projets sont réalisés en collaboration avec des partenaires tels le service local du
Réseau pour le développement des compétences par l'intégration des technologies
(RÉCIT) ou les personnes-ressources régionales de soutien et d'expertise. Ils sont
réalisés par les intervenants d'une école ou d'une commission scolaire.
Chaque projet doit faire clairement ressortir comment les TIC sont intégrées à la
démarche d'enseignement-apprentissage et doit être réalisé de façon à pouvoir être
diffusé et reproduit dans d'autres milieux.

Projet PRA
La recherche-action a comme objectif d'encourager le milieu scolaire et le milieu de la
recherche à collaborer pour développer l'expertise relativement à l'intervention auprès
des élèves handicapés ou en difficulté.
La recherche-action se vit dans l'action, sur le terrain, avec les avantages et les
ajustements que cela comporte. La recherche se développe ainsi en lien direct avec
les préoccupations des praticiens, et ces derniers peuvent profiter des connaissances
et de l'expertise rigoureuse des chercheurs pour améliorer leur intervention.
Ensemble, ils développent une dynamique d'acteur-chercheur, qui sert l'intérêt
commun des partenaires.
La recherche vise, par le développement des connaissances, à faire évoluer les
pratiques. Elle utilise une démarche rigoureuse, structurée, qui permet de fixer des
objectifs, d'évaluer l'atteinte des résultats et d'expliquer dans quelles conditions ces
résultats peuvent être obtenus. Elle doit être réalisée de telle sorte que la démarche
ou les résultats puissent être reproduits dans d'autres milieux, dans une optique de
transfert des connaissances.

159 de 273
Quelle est la procédure à suivre pour présenter un projet?
Les intervenants des écoles ou des commissions scolaires qui souhaitent
expérimenter une recherche ou un projet de développement pédagogique doivent
contacter la personne ou l'instance qui est mandatée par la commission scolaire pour
accueillir les propositions et convenir des projets qui répondent le mieux aux
exigences du programme. Cette personne, qui est généralement la coordonnatrice ou
le coordonnateur de l'adaptation scolaire de la commission scolaire, peut notamment
favoriser la collaboration entre les écoles pour la réalisation de projets. L'objectif est
de s'assurer que les projets répondent à tous les critères d'admissibilité établis par la
DAS.
Le projet doit être présenté en utilisant le formulaire approprié. Une description du
projet doit accompagner la demande. La collaboration de partenaires externes doit
être indiquée. Dans le cas d'une recherche-action, c'est l'apport des chercheuses et
des chercheurs du milieu collégial ou universitaire qui doit être précisé. L'expertise
des ressources régionales de soutien peut aussi être mise à contribution.
Compte tenu du budget disponible, le nombre de projets déposés par une
commission scolaire doit être limité. C'est la personne mandatée par la commission
scolaire qui achemine le projet à la personne responsable de l'adaptation scolaire de
la direction régionale du ministère de l'Éducation, du Loisir et du Sport de son
territoire, qui, à son tour, le transmettra à la Direction de l'adaptation scolaire du
Ministère aux fins d'analyse et de sélection, avec ses commentaires, s'il y a lieu.

Quels sont les critères d'admissibilité?

Compte tenu des sommes disponibles et de la quantité de projets reçus (environ 200
par année), ces derniers ne pourront pas tous bénéficier du soutien financier offert
dans le cadre de ce programme. Tout projet soumis doit satisfaire aux critères
d'admissibilité suivants :
• II présente des interventions qui concrétisent les orientations de la Politique de
l'adaptation scolaire;
• II met l'accent sur le développement des compétences de l'élève et du personnel
scolaire, en conformité avec le Programme de formation de l'école québécoise;
• II indique comment le milieu scolaire compte intégrer les résultats de
l'expérimentation dans sa pratique;
160 de 273
• II précise comment l'école ou la commission scolaire contribue concrètement à sa
réalisation (ressources humaines et financières);
• II nécessite une aide financière n'excédant pas 50 000 $ par projet;
• Exceptionnellement un projet qui s'échelonnerait sur deux années pourrait
bénéficier d'un montant maximal de 50 000 $ la première année et d'un montant
maximal de 25 000$ la deuxième année.
• II ne doit pas faire l'objet d'un autre financement ou correspondre aux objectifs
visés par d'autres mesures de soutien (Implantation de la réforme, Plans de
réussite, Agir-autrement, etc.);
• II est élaboré et réalisé avec la contribution de chercheuses et chercheurs
qualifiés du milieu de la recherche, dans le cas d'une recherche-action.

Quel est le processus de sélection des projets?

Un comité d'évaluation, constitué de représentants du ministère de l'Éducation, du
Loisir et du Sport et des partenaires concemés(Groupe de concertation en adaptation
scolaire, RÉCIT, etc.), analyse les projets admissibles en fonction :
• Du lien avec les objectifs du Programme de soutien à la recherche et au
développement en adaptation scolaire;
• De la cohérence avec le Programme de formation de l'école québécoise
(implication de l'élève, développement de compétences, etc.);
• Du caractère novateur (de l'approche, de l'intervention ou des modalités des
services);
• Du réalisme de la démarche (faisabilité);
• De l'impact espéré dans le milieu, à moyen et à long terme;
• De la possibilité de reproduire les résultats dans un autre milieu (transférabilité
des résultats);
• De la qualité méthodologique (valeur scientifique);
• De la qualité de la collaboration avec les partenaires concernés :
o Responsables du RÉCIT ou ressources régionales (TIC);
o Milieu de la recherche (recherche-action).

161 de 273
La sélection des projets se fait en fonction de ces exigences et du budget disponible.
Au besoin, la décision finale peut aussi prendre en considération la diversité des
clientèles visées et une certaine répartition régionale des projets sélectionnés. Les
écoles et les commissions scolaires sont informées au début de juin de la décision du
comité.

Quelles sont les dépenses autorisées?

Ce sont les dépenses qui excèdent les dépenses de fonctionnement de l'organisme
scolaire et qui sont liées directement à l'élaboration, à la réalisation et à l'évaluation
du projet, telles que :
• Les frais de suppléance ou de remplacement rattachés à la participation du
personnel, à l'élaboration, à la réalisation ou à l'évaluation du projet : rencontres,
production des rapports, etc.;
• Les honoraires de consultation liés à l'élaboration et à l'évaluation de la
démarche;
• Les frais liés à l'embauche d'assistantes et d'assistants de recherche (recherche-
action);
• Les autres dépenses essentielles à la réalisation du projet.

Quand peut-on soumettre un projet?

Le cycle de présentation des projets s'étale sur une année :
• Début septembre : envoi par la DAS du formulaire et de la lettre d'information
avisant les organismes scolaires et les DR sur le début de la réception des
demandes (propositions de projets à réaliser). L'organisme scolaire peut être un
établissement d'enseignement (EE) ou une commission scolaire (CS);
• 15 avril : approbation du projet (EE) proposé par la CS dont dépend l'EE;
• 29 avril : dépôt, à la Direction régionale du Ministère, des projets EE approuvés
par les CS et des projets CS;
• 13 mai : analyse et sélection des projets approuvés par les DR;
• 3 juin : envoi des réponses aux organismes scolaires (CS et EE);
• Septembre à mai : réalisation des projets;
• Fin mai : dépôt des bilans au Ministère.

162 de 273
5.4.2.3 Problèmes perçus par les personnes consultées

• Formulation non standardisée des demandes, ce qui complique l'analyse des

demandes et génère souvent des ambiguïtés résultant d'interprétations
différentes;
• II n'est pas toujours facile de pouvoir accéder instantanément aux documents
relatifs à une demande pour répondre rapidement aux sollicitations;
• Difficulté de réaliser un suivi rigoureux compte tenu de la masse de documents
reçus;
• Absence de statistiques sur les demandes, les projets, les refus, les subventions,
etc.;
• Arrivée tardive des informations de la part des partenaires, compte tenu des
délais de la poste et des nombreux échanges téléphoniques ou par courriel avant
de cerner l'information demandée;
• Mise à jour manuelle des demandes pouvant entraîner des erreurs de
retranscription;
• Difficulté de consultation de l'historique des demandes sous format papier.
• Mise à jour manuelle de la liste des organismes scolaires et des partenaires, ce
qui se traduit par de nombreuses erreurs et de nombreux retours d'envois.

5.4.3 Identification des domaines

Organigramme de la PAS

DAS

Politiques et règlements Suivi des déficiences et évaluation Gestion des budgets

EHDAA des programmes

Figure 27 diagramme d'organisation de la DAS

163 de 273
Liste des domaines de la DAS

Fiche 01 Liste des domaines Date : 2005-09-13

Unité
Direction de l'adaptation scolaire (DAS)
organisationnelle

Code unité UO01

Code domaine Domaine Description

• Elaboration des orientations,

Définition des politiques et
UO01_D01 politiques et règlements des
règlements EHDAA programmes EHDAA.
• Définition de la clientèle EHDAA.
• Définition des types de
Suivi des déficiences et déficiences.
• Élaboration de la carte des
UO01_D02 évaluation des services offerts et évaluation des
programmes programmes.
• Soutien à la réalisation de projets
EHDAA.
• Planification du budget.
UO01_D03 Gestion du budget • Répartition du budget.
• Suivi des ressources financières.

Tableau 44 Liste des domaines de la DAS

5.4.4 Identification des processus métier

Pour chaque domaine tel que décrit dans le Tableau 45, il s'agit d'identifier les
processus métier qui le composent. Il faut avouer qu'il n'y a pas de recette miracle
pour identifier les processus métier. Toutefois, la majorité des processus sont
implicitement identifiables par la nature même du domaine considéré. Pour cela, nous
nous sommes basés sur la documentation collectée, sur la description du domaine et
sur l'avis des personnes connaissant bien le domaine.
Le résultat de cette activité est la liste des processus métier composant chaque
domaine identifié. Le résultat est illustré dans les tableaux qui suivent.

164 de 273
Domaine : Définition des politiques et rèalements EHDAA

Liste des processus métier Date : 2005-09-

Fiche 02.01
19
Unité Direction de l'adaptation
Code unité : U01
organisationnelle scolaire (DAS)
Définition des politiques et
Domaine Code domaine : U01_D01
règlements EHDAA

Code processus Description

• Collaborer à la définition, à
l'évaluation ou à la révision
du cadre légal et
réglementaire de l'adaptation
Élaboration des scolaire.
orientations, politiques et • Élaborer, évaluer et réviser
UO01_D01_P01 règlements des les politiques et orientations
programmes EHDAA. au regard des services
éducatifs adaptés aux
besoins des élèves
handicapés ou en difficulté
d'adaptation et
d'apprentissage.

• Élaborer les définitions du

Ministère, de la clientèle
EHDAA.
Définition de la clientèle
UO01_D01_P02 • Collaborer avec les
EHDAA. partenaires (milieu de la
santé, Commissions
scolaires, écoles, etc.) pour
la mise à jour des définitions.

Tableau 45 Liste des processus métier du domaine «Définition des politiques et

règlements EHDAA»

165 de 273
Domaine : Suivi des déficiences et évaluation des programmes

Fiche 02.02 Liste des processus métier Date: 2005-09-19

Unité Direction de l'adaptation

Code unité : U01
organisationnelle scolaire (DAS)
Suivi des déficiences et
Domaine évaluation des Code domaine : U01 D02
programmes

Processus métier >cr.

''•: ••• • - •

Programme de soutien à Gérer toutes les informations

sur les demandes des
la recherche et au organismes scolaires
UO01 D02 P01 développement en (références du demandeur,
type de projet, description du
adaptation scolaire projet, subvention demandée,
(SoReDAS) subvention accordée, Bilan du
projet, etc.).
Présenter les définitions du
Ministère et préciser les
critères d'interprétation que
celui-ci utilise dans sa
validation annuelle de la
déclaration des effectifs
scolaires. L'objectif est de
favoriser l'interprétation la plus
Déficiences et élèves à homogène possible des
UO01 D02 P02 définitions et des
risque
caractéristiques des divers
groupes d'élèves considérés.
Catégoriser les classes
d'élèves handicapés et à risque
(Déficience motrice légère ou
organique, déficience
langagière, déficience
intellectuelle, troubles relevant
de la psychopathologie, etc.)
• Réviser et évaluer le régime
UO01 D02 P03 Régimes pédagogiques pédagogique afin de maintenir
ou de modifier certains
éléments en fonction des

166 de 273
 besoins.
• Assurer le suivi de son
application et des moyens
retenus.
• Informer les partenaires
concernés.
• Élaborer des brochures
d'information, des guides
d'organisation et des
documents de soutien en vue
Parcours accès sur
UO01_D02_P04 de l'insertion sociale et
l'emploi professionnelle d'élèves en
difficultés d'adaptation ou
d'apprentissage et présentant
un retard important dans les
matières de base.

Tableau 46 Liste des processus métier du domaine «Suivi des déficiences et évaluation
des programmes»

Domaine : Gestion du budget

Fiche 02.03 Liste des processus métier Date : 2005-09-19

Unité Direction de l'adaptation

Code unité : U01
organisationnelle scolaire (DAS)

Domaine Gestion du budget Code domaine : U01_D03

Code processus Processus métier Description

• Collaborer à la définition des

Planification et répartition règles budgétaires.
UO01_D03_P01 du budget • Définir les règles de gestion.
• Planifier et répartir le budget en
fonction des besoins.
UO01_D03_P02 Suivi des ressources
• Assurer le suivi du budget.
financières
Tableau 47 Liste des processus métier du domaine «Gestion du budget»

5.4.5 Définition de la frontière du processus métier objet

Rappelons que le processus métier objet de la présente étude est celui dénommé
Programme de soutien à la recherche et au développement en adaptation scolaire

167 de 273
 (SoReDAS), pour lequel nous allons essayer de déterminer la frontière selon le
principe énoncé dans la méthode proposée dans ce mémoire (cf. chapitre 4).
Pour ce faire, nous avons utilisé les résultats de la clarification de la demande et des
entrevues réalisées avec les différents intervenants et principalement la responsable
du programme de soutien, ainsi que les résultats de l'identification des domaines (cf.
4.5.3) et de l'identification des processus métier (cf. 4.5.4).
Le résultat de la définition de la frontière du PM objet est le Tableau 28 qui consiste
en une description sommaire des composantes du processus métier objet.

Corn posants Description

• Formulaire renseigné de projet recherche-action.
• Formulaire renseigné de projet TIC.
• Budget alloué.
• Bilan du projet.
• Caractéristiques de l'organisme scolaire (Établissement
d'enseignement, Commission scolaire). Ces
caractéristiques concernent : nom organisme,
Entrées coordonnées, secteur d'enseignement, nom du
responsable, coordonnateur des programmes de la
DAS, chercheurs impliqués.
• Approbation, par la CS, de la demande émise par
l'établissement d'enseignement relevant de son autorité.
• Approbation, par la DR, de la demande émise par
l'établissement d'enseignement ou par la CS relevant
de son autorité.
• Etablissement d'enseignement.
• Commission Scolaire.
Acteurs (Fournisseurs des
• Direction régionale.
entrées)
• PM Gestion du budget.
• Comité ministériel d'évaluation des projets proposés.
• Lettre d'information.
• Formulaire vierge de projet recherche-action.
Formulaire vierge de projet TIC.
• Réponse de la DAS (Approbation ou refus),
Sorties
• Subvention accordée.
• Rapport statistique.
• Ventilation des subventions.
• Synthèse des bilans.
• Etablissement d'enseignement.
• Commission scolaire.
Acteurs (Destinataires des
• Direction régionale.
sorties
• PM Gestion du Budget.
• Partenaires du Ministère (universités, cégeps,

168 de 273
 Composante
•
chercheurs).
• Comité ministériel d'évaluation des projets proposés.
• Description sommaire de l'activité générale du
processus métier objet :
• Élaboration et envoi d'une lettre d'information aux
organismes scolaires;
• Élaboration et envoi des formulaires de proposition de
projet;
• Réception, vérification et analyse du projet proposé;
• Transmission du projet au comité d'évaluation;
Activités • Réception de l'acceptation ou du refus du comité
ministériel d'évaluation.
• Envoi de la réponse aux organismes scolaires;
• Réception du bilan du projet accepté;
• Élaboration de la synthèse des bilans et envoi aux
partenaires et aux organismes scolaires.
• Élaboration de statistiques (projets acceptés, projets
refusés, subvention par projet, total des subventions,
etc.)
• Responsable du programme de soutien.
Acteurs effectuant les activités • Secrétaire qui reçoit et classe les demandes.
du PM objet • Professionnel qui vérifie et analyse les demandes.
• Processus d'évaluation des projets par le comité
ministériel d'évaluation.
• Envoi des subventions.
Activités exclues du PM objet • Processus d'approbation, par la CS, des projets des
établissements d'enseignement sous son autorité.
• Processus d'approbation, par la DR, des projets des EE
ou CS relevant de son autorité administrative.

Tableau 48 Les déterminants de la frontière du processus métier objet

5.4.6 Modèle de contexte du PM objet

Cette étape a pour but de modéliser le contexte du PM objet. À ce stade, le

processus est considéré comme une boite noire (on ne s'intéresse pas au comment
se font les choses) et il s'agit alors de compléter l'identification (abordée lors de la
définition des frontières du PM objet) des acteurs qui interagissent directement avec
le processus métier, ainsi que leurs interactions (messages échangés) en
représentant l'ensemble des interactions sur le modèle de contexte dynamique

169 de 273
présenté dans la Figure 28. Nous nous intéressons uniquement aux acteurs externes
au PM objet et non aux intervenants « internes » qui effectuent les tâches au sein du
PM Objet. Ces derniers seront pris en compte lors de la phase de diagnostic de
l'existant.
Le Tableau 30, ci-après, fournit la liste des acteurs externes et leurs échanges avec
PM objet.

170 de 273
Fiche 03 Liste des acteurs externes Date : 2004-09-21

Unité
Direction de l'adaptation scolaire (DAS) Code unité : U01
organisationnelle

Domaine Suivi des déficiences et évaluation des programmes Code domaine : U01_D02
Programme de soutien à la recherche et au développement en
Processus métier Code processus : UO01_D02_P01
adaptation scolaire (SoReDAS)

Code acteur Acteur Description (intention/Service attendu) Messages émis/reçus

Émet : Projet, Bilan.

Établissement Proposer un projet et obtenir une subvention Reçoit : Lettre d'information,
UO01_D02_P01_AC01
d'enseignement(EE) pour le réaliser. Formulaire de demande, Réponse de
la DAS, Subvention.
Emet : Approbation Projet EE, Projet
Approuver le projet proposé par
initié par la CS, Bilan.
l'établissement d'enseignement sous sa
Commission Reçoit ; Lettre d'information,
UO01_D02_P01_AC02 tutelle. La CS peut également proposer un
Scolaire (CS) Formulaire de demande, Réponse de
projet et obtenir une subvention pour le la DAS, Subvention pour projet initié
réaliser. par la CS.
Émet : Approbation Projet soumis par
Approuver le projet proposé par la CS et
Direction régionale EE et/ou par CS.
UO01_D02_P01_AC03 celui de l'établissement d'enseignement
(DR) Reçoit : Lettre d'information,
approuvé par la CS.
Réponse de la DAS, Bilan.
Émet ; Avis sur le projet (acceptation
Comité ministériel Évaluer le projet proposé et émettre un avis ou refus)
UO01_D02_P01_AC04
d'évaluation d'acceptation ou de refus de subvention. Reçoit : Rapport du professionnel de
la DAS sur le projet proposé.

171 de 273
Fiche 03 Liste des acteurs externes Date : 2004-09-21

Unité
Direction de l'adaptation scolaire (DAS) Code unité : U01
organisationnelle

Domaine Suivi des déficiences et évaluation des programmes Code domaine : U01_D02
Programme de soutien à la recherche et au développement en
Processus métier Code processus : UO01_D02_P01
adaptation scolaire (SoReDAS)

Code acteur Acteur Description (intention/Service attendu) Messages émis/reçus

Fournir le montant du budget alloué au

PM « Gestion du Émet : Montant alloué au programme.
UO01_D02_P01_AC05 programme et recevoir la liste des
budget» Reçoit : Subventions accordées.
subventions accordées.

Partenaires du
Ministère
Recevoir des informations sur les projets Émet : Rien.
UO01_D02_P01_AC07 (universités,
approuvés par la DAS. Reçoit : Bilan.
cégeps,
associations)

Tableau 49 Liste des acteurs du processus métier « SoReDAS »

172 de 273
Après avoir défini les acteurs et les messages échangés avec le système, le diagramme
de contexte se présente comme montré dans la Figure 28 ci-après:

Lettre d'information
Forrrulai re de demande
Réponse Lettre ainformabon
Subvention Réponse
Bilan Rapporta"

COMITÉ
DÉVALUATION

Approbation Projet
Projet initié
Bi

Réponse
Formjaire de demande PAR1ENWRES

Figure 28 Diagramme de contexte du processus métier SoReDAS

A la suite de la présentation des travaux de l'étude préliminaire et de leur validation par

le demandeur et ses collaborateurs, nous pourrons débuter la phase de diagnostic.

173 de 273
 5.5. La phase du diagnostic de l'existant

Les principaux objectifs du diagnostic de l'existant sont de définir les modèles du PM

objet, d'énumérer les problèmes et leurs causes ainsi que les objectifs que doit atteindre
le PM objet une fois transformé et de suggérer quelques éléments de solution qui
permettent d'atteindre ces objectifs.
Les étapes proposées pour mener cette phase sont :
• Planification du diagnostic de l'existant;
• Analyse de l'environnement;
• Collecte de l'information sur le PM objet;
• Modélisation du PM objet;
• Diagnostic de l'existant;
• Présentation des résultats du diagnostic.

5.5.1 Planification du diagnostic de l'existant

5.5.1.1 Formation de l'équipe

Unité
Ressource11 Fonction Rôle Coordonnées
administrative
Volontairement
RI DAS Gestionnaire Valider les objectifs
non fournies
Fournir les informations
Responsable du
R2 DAS sur le PM objet et valider
programme
les biens livrables
Fournir les informations
Responsable du sur le PM « Gestion du
R3 DAS
budget budget » et valider les
biens livrables
Chargé de projet Recueillir les besoins et
A.S (Ali Saadi) Laval
et analyste modéliser

Tableau 50 Ressources affectées au projet

11
Les noms et coordonnées des personnes qui ont participé à cette étude ont été masqués pour des raisons de
confidentialité.
174 de 273
5.5.1.2 Échéancier des travaux

• • • . . - • . .

Activité Date début Date fin Responsable Participants

Planification du diagnostic de
2005-10-03 2005-10-03 A.S R2, R3
l'existant
Analyse de l'environnement 2005-10-03 2005-10-05 A.S R2, R3
Collecte de l'information sur le PM
2005-09-05 2005-10-07 A.S R2., R3
objet
Modélisation du PM objet 2005-10-07 2005-10-14 A.S R1, R2, R3
Diagnostic de l'existant 2005-10-17 2005-10-28 A.S R2, R3. R4 R5
Présentation des résultats du
2005-10-31 2005-10-31 A.S
diagnostic

Tableau 51 Échéancier des travaux

5.5.1.3 Choix des outils de travail

Sources d'information utilisées :

• Gestionnaire de la DAS (R1 );
• Responsable du processus métier (R2);
• Responsable du budget (R3);
• Responsable de la gestion des dossiers des organismes scolaires (R5);
• Responsable de la sécurité informatique (R4);
• Documentation disponible à la DAS.

Méthodes de collecte d'information utilisées :

• Entrevues;
• Lecture de la documentation.

Une fois la planification du diagnostic réalisée et validée par les décideurs, notamment
par le demandeur, nous pouvons passer à l'étape d'analyse de l'environnement du PM
objet afin de le situer par rapport à son environnement et de connaître l'impact de l'un
sur l'autre.

175 de 273
5.5.2 Analyse de l'environnement du PM objet

Lois, règles et politiques auxquelles l'UO organisationnelle est soumise

• Régime pédagogique de l'éducation préscolaire, de l'enseignement primaire et de

l'enseignement secondaire (Loi sur l'instruction publique L.R.Q., c. 1-13.3, a. 447).
• Règlement sur le régime des études collégiales (Loi sur les collèges d'enseignement
général et professionnel L.R.Q., c. C-29, a. 18).
• Régime pédagogique de la formation générale des adultes (Loi sur l'instruction
publique L.R.Q., c. 1-13.3, a. 448)
• Régime pédagogique de la formation professionnelle (Loi sur l'instruction publique
L.R.Q., c. 1-13.3, a. 449)
• Charte de la langue française L.R.Q., c. C-11, a. 97.
• Règlement sur l'exemption de l'application du premier alinéa de l'article 72 de la Charte
de la langue française qui peut être accordée aux enfants présentant des difficultés
graves d'apprentissage (Charte de la langue française L.R.Q., c. C-11, a. 81 et 93).
• Politique de l'adaptation scolaire : Gouvernement du Québec, Ministère de l'Éducation,
1999 — 99-0798.
• Politique du Conseil supérieur de l'Éducation : L'intégration scolaire des élèves
handicapés et en difficulté, Avis à la ministre de l'Éducation, Québec, 1996, p. 6.
• L'orientation fondamentale et les voies d'action de la Politique de l'adaptation scolaire
Ministère de l'Éducation, 2004-03-00557.
• Règles budgétaires découlant de la Loi sur l'instruction publique (L.R.Q., c. 1-13.3;
1997, chapitre 96, article 143).

Liste complétée des messages échangés entre le PM objet et ses acteurs externes

• On peut se limiter à celle déjà établie lors de la modélisation du contexte (cf. Tableau
30 et Figure 28) car elle a été jugée complète par le demandeur.

176 de 273
Tendances technologiques de l'UO à court et moyen termes
• Arrimage avec l'infrastructure départementale du Ministère qui utilise les outils de
développement Oracle et Windows XP.
• Utilisation d'Internet pour communiquer avec les clients et les partenaires.
• Utilisation des systèmes serveurs : le Ministère dispose de systèmes dits « systèmes
serveurs », indépendants des applications informatiques et dont la fonction principale
est de gérer toutes les opérations relatives aux BD et aux accès des usagers. Les PM
automatisés n'ont pas à se préoccuper de ces aspects. Cette politique permet, au
Ministère, une grande réutilisation de services déjà mis en place et qui sont communs
à la quasi-totalité des applications informatiques.

Parties automatisées du PM objet

• Aucune.

Données confinées (Bases de données, fichiers, etc.)

Donnée Description Support

Établissements
Caractéristiques des EE. Excel
d'enseignement (EE)
Commissions scolaires
Caractéristiques des CS. Excel
(CS)
Informations sur les des intervenants
Intervenants des EE (nom, organisme scolaire d'appartenance, Excel
adresse, courriel, téléphone, etc.)
Informations sur les des intervenants
Intervenants des CS (nom, organisme scolaire d'appartenance, Excel
adresse, courriel, téléphone, etc.)
Partenaires du Informations sur les partenaires (nom,
Excel
Ministère. adresse, courriel, téléphone, etc.)
Description sommaire des projet proposés
Liste des projets (objet, type, provenance, accepté/refusé
Word
proposés. subvention demandée, subvention
accordée)
Etat des subventions Ventilation des subventions par année,
Excel
accordées. par projet, par EE, par CS et/ou par DR
Document texte contenant le bilan élaboré
Bilans des projets. Word
par le propriétaire du projet subventionné.
177 de 273
 Modèles de lettres
Ensemble de gabarits de lettres
d'information et de Word
d'information et de réponses de la DAS.
réponse.
Tableau 52 Données confinées

5.5.3 Information sur le PM objet

Rappelons qu'à ce niveau de l'étude, le PM objet n'est plus considéré comme une boite
noire vue seulement de l'extérieur, mais plutôt comme un système ouvert pour lequel on
désire comprendre comment il fonctionne. Pour le PM objet ainsi vu, la collecte
d'information a porté sur les trois dimensions énoncées lors de la description de la
méthode proposée (cf. chapitre 4), à savoir ses composantes, ses performances et ses
problèmes.
C'est encore une fois par le biais des entrevues, de l'analyse de la documentation et de
l'observation que nous avons collecté l'information sur le PM objet.

5.5.4 Collecte de l'information sur les composantes

Le Tableau 32 (qui reprend en partie le Tableau 28) rappelle ce que sont les
composantes essentielles d'un PM. C'est donc sur ces composantes qu'on a recueilli
des données afin de compléter l'information déjà accumulée.

L'information recueillie à ce niveau est synthétisée dans le tableau Tableau 32, ci-après.
Toute l'information ainsi collectée sera organisée et formalisée plus tard, sous formes
de modèles qui seront décrits dans l'étape de modélisation du PM objet (cf. 4.6.7).

s . < M - - \ / - \ • :. •• • • : •••.••, , •.. . - . • '

Composante Description

Acteurs effectuant • Responsable du programme de soutien.

les activités du PM • Secrétaire qui reçoit et classe les demandes.
objet • Professionnel qui vérifie et analyse les demandes.
Messages • Projet de lettre d'information.
échangés entre les • Projet de formulaire de demande.
acteurs internes • Liste des partenaires du Ministère.

178 de 273
 • Critères d'admissibilité.
• Copie de la demande (projet proposé).
• Liste des projets reçus.
• Rapport d'analyse de la demande.
• Avis de non-conformité d'une demande.
• Avis du comité d'évaluation.
• Projet de réponse de la DAS (Approbation ou refus).
• Subvention accordée.
• Rapports statistiques (liste des projets par type, État des
projets acceptés, État des subventions accordées).
• Synthèse des bilans.
L'activité principale de ce processus métier consiste à recueillir les
projets proposés par les établissements d'enseignement publics et
par les CS, à les analyser pour s'assurer de leur conformité par
rapport aux critères d'admissibilité établis par le Ministère et à
élaborer un rapport d'analyse par projet. Ce rapport est soumis à
un comité d'évaluation qui accepte ou refuse le projet en question.
Suite à cette évaluation, la DAS envoie la réponse du comité
d'évaluation au soumissionnaire. Les projets acceptés reçoivent
alors une subvention. A l'issue de la réalisation du projet
subventionné, la DAS reçoit un bilan qu'elle met en forme
Activités (correction linguistique, synthèse et présentation) et le diffuse aux
partenaires du Ministère ainsi qu'aux DR.
Ce processus métier se compose des activités suivantes :
• Élaborer et envoyer la lettre d'information et les formulaires
aux organismes scolaires;
• Réceptionner le projet proposé;
• Élaborer le rapport d'analyse du projet proposé et le
soumettre au comité d'évaluation;
• Élaborer la synthèse des bilans et envoyer aux partenaires.
• Élaborer les statistiques (projets acceptés, projets refusés,
subvention par projet, total des subventions, etc.)

5.5.5 Collecte de l'information sur les performances

L'objectif de cette activité est de collecter des données sur les performances du PM
objet (critères d'efficacité et d'efficiencej. Ces données permettent de l'évaluer par
rapport aux objectifs énoncés lors de l'étude préliminaire.
C'est avec différents intervenants, notamment la responsable du programme et du
professionnel de la DAS qui analyse les projets proposés que nous avons déterminé les

179 de 273
 besoins et les attentes en ce qui a trait à ces critères. Le résultat de cette activité est
synthétisé dans le Tableau 33 et le Tableau 34.

. Valeur
Critère Description souhaitée
• Délai d'élaboration du formulaire de < 1 mois
demande.
Rendre la sortie • Délai d'élaboration du rapport < 5 jours
Disponibilité
(output) disponible d'analyse par demande.
au moment < 2 mois
au moment • Délai d'élaboration de la synthèse des
désiré
opportun. bilans.
• Délai d'approbation des projets par la
DAS. < 20 jours
Conformité des
Conformité
projets par rapport
aux • Taux de projets non conformes. < 20%
aux critères
spécifications
d'admissibilité
• Taux d'erreur dans liste des EE.
• Taux d'erreur dans liste des CS.
• Taux d'erreur dans liste des
intervenants EE.

o o o o o
• Taux d'erreur dans liste des
Exactitude et intervenants CS.
Fiabilité
précision • Taux d'erreur dans liste des
partenaires du Ministère.
• Nombre de plaintes pour les projets
refusés.

o o
• Nombre de lettres retournées par
erreur d'adresse.
• Temps écoulé entre l'approbation et
La rapidité avec 5 jours
l'envoi de la subvention.
Rapidité du laquelle une 20 jours
service activité produit un • Temps écoulé entre l'élaboration de la
service. synthèse des bilans et son envoi aux
partenaires.
Tableau 54 Les critères d'efficacité des sorties (outputs) d'un PM

Valeur
Critère Description Mesure d'évaluation souhaitée
• Durée d'élaboration du formulaire de 10 jours
demande.
• Durée d'élaboration de la lettre 0.5 jour
Durée de
Temps réel d'information.
traitement d'une
de traitement • Durée d'élaboration des critères 5 jours
transaction.
d'admissibilité.
• Durée de la vérification de la 0.5 jour

180 de 273
 conformité d'une demande.
• Durée d'élaboration du rapport 1 jour
d'analyse d'un projet.
• Durée d'élaboration de la synthèse des 1,5 mois
bilans.
• Durée d'élaboration et d'envoi de la 0.25 j
réponse de la DAS.
• Durée d'élaboration de la ventilation 5 jours
des subventions.
• Durée d'élaboration des statistiques 15 jours
sur les demandes
• Nombre projets vérifiés par jour. 10
• Nombre de lettres envoyées par jour
Nombre de 200
(saisie des adresses, insertion des
Nombre de transactions
formulaires et de la lettre
transactions exécutées par les
d'information).
acteurs. 10
• Nombre de réponses envoyées par la
DAS par jour.
• Délai avant que l'avis du comité
Durée d'attente 5 jours
d'évaluation soit fourni à la DAS.
Temps d'une transaction
• Délai avant que les listes des EE, CS,
d'attente avant d'être 2 mois
intervenants et partenaires soient
traitée.
mises à jour.
Tableau 55 Les critères d'efficience d'un PM

5.5.6 Collecte de l'information sur les problèmes

Au cours de l'étude préliminaire, nous nous sommes déjà intéressés à la perception

qu'ont les divers intervenants sur les problèmes du PM objet, notamment lors de la
clarification de la demande où ils auraient pris en compte la vision générale du
demandeur sur les problèmes.
L'objectif de cette activité est de prendre en compte tous les problèmes identifiés et
leurs causes probables. Il ne s'agit pas à ce niveau de trouver des solutions aux
problèmes énoncés mais simplement de les répertorier et de trouver les causes
probables. Les solutions seront proposées lors de la phase de l'analyse (cf. section 4.7).
Pour ce faire, nous avons établi avec la responsable du programme, le professionnel et
la secrétaire de la DAS, la fiche décrite dans le Tableau 35, ci-après.

181 de 273
Fiche 04 Liste des problèmes et causes probables Date: 2005-10-24
Direction de
Unité
l'adaptation scolaire Code unité : U01
organisationnelle
(DAS)
Suivi des déficiences
Domaine et évaluation des Code domaine : U01_D02
programmes
Programme de
soutien à la
recherche et au
Processus métier Code processus : UO01_D02_P01
développement en
adaptation scolaire
(SoReDAS)
Énoncé du problème Source Cause probable
Différentes Formulation non standardisée des
interprétations du Responsable du demandes conduisant à des
contenu du formulaire programme interprétations différentes des textes
de demande rédigés par le demandeur.
L'accès aux dossiers papier des
Difficulté de répondre demandeurs n'est pas efficace (temps de
rapidement aux recherche, mauvais classement, absence
Secrétaire
sollicitations des d'employé, dossier non à portée de main,
demandeurs etc.).

• Masse importante de documents reçus.

Difficulté de faire une
vérification et un suivi
Professionnel • Nombre de ressources insuffisantes (3
rigoureux des
personnes pour gérer le programme de
demandes
soutien).
• Responsable du Absence d'indicateur dans le dossier du
Difficulté de connaître
programme demandeur. On se base souvent sur la
l'état courant d'une
• Professionnel mémoire individuelle pour fournir une
demande réponse au demandeur.
• Secrétaire
• Absence de statistiques détaillées et de
tableaux de bord. Les statistiques qui
existent sont sommaires et réalisées via
Difficulté de cerner les
Responsable du des outils élémentaires tels que Excel.
résultats des travaux
programme • Absence d'information sur les EE ou CS
de la DAS
qui n'ont jamais formulé de demandes
afin de chercher, éventuellement, le
pourquoi.

182 de 273
Fiche 04 Liste des problèmes et causes probables Date: 2005-10-24
Direction de
Unité
l'adaptation scolaire Code unité : U01
organisationnelle
1DAS)
Suivi des déficiences
Domaine et évaluation des Code domaine : U01_D02
programmes
Programme de
soutien à la
recherche et au
Processus métier Code processus : UO01_D02_P01
développement en
adaptation scolaire
igoReDAS)
i:!i[i!Mink<;tv 4n \<m44<vm--! Source Cause probable
• Délai de la poste.
• Nombreux échanges téléphoniques ou
Arrivée tardive de • Responsable du par courriel entre le demandeur et la DAS
plusieurs demandes programme avant de cerner l'information demandée.
(au-delà du délai fixé • Professionnel • Nombreuses pièces jointes au formulaire
par la DAS) • Secrétaire de demande.
• Aucune contrainte obligeant le
demandeur à respecter le délai.
Les mises à jour et les rectifications
envoyées par le demandeur sont
Erreurs fréquentes lors • Responsable du
transcrites manuellement dans le
de la transcription des programme formulaire original. Cette transcription
mises à jour • Professionnel entraîne souvent des erreurs et peut
parfois être oubliée.
• Responsable du
Difficulté d'avoir une • L'information sur les changements n'est
programme
liste à jour des EE des pas toujours disponible.
• Professionnel
CS et des partenaires • Mise à jour manuelle et occasionnelle.
• Secrétaire
Difficulté de consulter
Responsable du
l'historique des Dossiers sous format papier.
programme
demandes
Tableau 56 Liste des problèmes et leurs causes probables

183 de 273
5.5.7 Modélisation du PM objet

L'objectif de cette étape est de décrire Le PM objet au moyen d'outils graphiques afin de
mieux en comprendre le fonctionnement et d'être à même de poser le diagnostic à son
sujet. Les modèles résument en quelque sorte toute l'information collectée.
Lors de la collecte d'information sur le PM objet (cf. 4.6.3), nous avons préparé la liste
des acteurs et des messages échangés et la liste des activités composant le PM objet.
À partir de ces éléments, nous pouvons commencer la modélisation proprement dite du
PM objet.
Pour la modélisation du PM objet, nous présentons d'abord, un modèle global du PM
objet et de ses sous-processus (cf. Figure 22) puis un modèle détaillé de chacun des
sous-processus (cf. Figure 23 à Figure 37).

5.5.7.1 Construction du modèle global du PM objet

L'objectif de ce modèle est de montrer l'enchaînement des activités au sein du PM objet

vu sous un aspect macroscopique sans trop de détails, ainsi que les échanges de ce
dernier, en termes d'entrées et de sorties (inputs/outputs), avec son environnement.
Pour élaborer ce modèle, nous nous sommes basés sur les résultats de l'étude
préliminaire (liste des acteurs externes, liste des messages, diagramme de contexte) et
sur le complément d'informations résultant de l'activité de collecte de l'information sur le
PM objet (cf. 4.6.3), notamment la liste des acteurs internes, les messages échangés et
la liste des activités du PM objet.

Selon les informations recueillies, le PM objet est constitué des sous-processus

suivants :
• Élaborer (par la responsable du programme) le formulaire de demande de subvention
et la lettre d'information avisant les organismes scolaires du début de la réception des
propositions de projets;
• Saisir (par la secrétaire) le formulaire de demande ainsi que la lettre d'information;

184 de 273
 Valider (par la responsable du programme) les informations saisies dans le formulaire
et la lettre d'information;
Envoyer (par la secrétaire) le formulaire et la lettre d'information aux organismes
scolaires (CS et EE). La lettre d'information est également envoyée aux DR;
Réceptionner (par la secrétaire) le projet proposé par un organisme scolaire ainsi que
l'approbation de la DR dont dépend l'organisme scolaire concerné;
Analyser (par le professionnel de la DAS) le projet proposé et élaborer un rapport
d'analyse qui est soumis au Comité d'évaluation. Si l'avis du Comité d'évaluation est
positif, une subvention est envoyée à l'organisme scolaire concerné; sinon, ce dernier
reçoit un avis de rejet;
Élaborer (par le professionnel de la DAS) le rapport de synthèse des bilans : Pour les
projets subventionnés, chaque bénéficiaire envoie un bilan de son projet. Le
professionnel élabore une synthèse des différents bilans qu'il envoie aux organismes
scolaires, aux DR et aux partenaires du Ministère afin de les informer des réalisations
et, éventuellement, faire généraliser certaines bonnes pratiques;
Élaborer (par le professionnel de la DAS) des statistiques : II s'agit de la réalisation
d'un ensemble de tableaux statistiques reflétant l'activité réalisée au sein du PM objet
(Nombre de projets reçus, projets refusés, projets acceptés, subventions accordées,
etc.).

La Figure 29, ci-après, décrit le modèle global du PM Objet.

185 de 273
Figure 29 Modèle global du PM objet SoReDAS

186 de 273
5.5.7.2 Construction des modèles des sous-processus du PM objet

Une fois le modèle global soumis aux divers intervenants et validé, nous avons procédé
à l'élaboration des modèles des sous-processus métier (ss-pm) composant le PM objet.
Ces sous-processus sont :
• Élaborer formulaire et lettre d'information;
• Saisir formulaire et lettre d'information;
• Valider formulaire et lettre d'information;
• Envoyer formulaire et lettre d'information;
• Réceptionner projet;
• Analyser projet;
• Élaborer synthèse des bilans;
• Élaborer statistiques.

Les modèles de ces ss-pm sont schématisés dans les figures 30 à 37, présentées dans
les sections qui suivent.

5.5.7.3 Modèle du ss-pm 1- Élaborer formulaire et lettre d'information

Le sous-processus « 1-Élaborer formulaire et lettre d'information » est activé lorsque la

responsable du programme reçoit du « PM Gestion du budget » l'information sur le
budget alloué au programme de soutien et de recherche-action. Elle élabore alors, un
formulaire de demande de subvention ainsi qu'une lettre pour informer les organismes
scolaires du début la réception des demandes et des critères d'admissibilité. Le
formulaire et la lettre d'information sont ensuite envoyés au ss-pm «2- Saisir formulaire
et lettre d'information» à des fins de saisie et d'enregistrement.

187 de 273
 »„,,.,
Acteur Enchaînements et produits du tous-processus 1- Élabom formu/aire et lettre d'information

Responsable du .1- Élaborer formulaire 1.2- Élaborer lettre d'information

UO01 002 PÛ1 AC07
programme

Sous-processus
UO01 D02 P01 SSPM02 "2- Sa/sir formulaire et Formulaire Lettre d'Information
lettre d'information'

Budget du
UO01 D02 POI AC05 PM "Gestion du budget" programme

Figure 30 Modèle du sous-processus «1- Élaborer formulaire et lettre d'information»

5.5.7.4 Modèle du ss-pm 2- Saisir formulaire et lettre d'information

L'objectif de ce ss-pm est rendre sous forme électronique les projets de formulaire et de
lettre d'information produits par le sous-pm «1- Élaborer formulaire et lettre
d'information». La secrétaire procède à leur saisie et à leur enregistrement, sous format
Word, dans un répertoire sur son poste. Une copie papier est envoyée à la responsable
du programme pour validation.

Code acteur ou PM Enchaînement

Lettre d'Information
.ton
Responsable du Lattre d'information
UO01_D02_P01_AC07
programme

2 3- Enregistrer formulaire
2.1-Saisir formulaire 2.2- Saisir lettre d'information
UO01 D02 P01 AC08 Secrétaire et lettre d'information

Registre des
formulaires et I

Figure 31 Modèle du sous-processus «2- Saisir formulaire et lettre d'information»

188 de 273
5.5.7.5 Modèle du ss-pm 3- Valider formulaire et lettre d'information

L'objectif de ce ss-pm est de valider le contenu du formulaire et de la lettre

d'information. Il est activé par l'envoi, de la part de la secrétaire, des copies du contenu
saisi sous forme électronique du formulaire et de la lettre d'information. La responsable
du programme procède aux corrections éventuelles et renvoie à la secrétaire les
documents validés.

CodeacteurouPM Enchaînements et produits du sous-processus 3- Valider formulaire et lettre information

Lettre d'information
UO01 002 P01 AC08 Secrétaire

Responsable-du 3.1-Valider formulaire 3.2- Valider lettre d'information

UO01 D02 P01 AC07
programme

Figure 32 Modèle du sous-processus «3- Valider formulaire et lettre d'information»

5.5.7.6 Modèle du ss-pm 4- Envoyer formulaire et lettre d'information

Ce ss-pm est activé lorsque la secrétaire reçoit le formulaire et la lettre d'informations

validés par la responsable du programme. Elle procède aux corrections éventuelles et
met à jour son registre des formulaires et des lettres. Ensuite, elle les envoie par poste
aux organismes scolaires (EE et CS) et aux directions régionales du Ministère (environ
9600 envois).

189 de 273
 4.1-Mettre à jour registre
des formulaires et lettres

Figure 33 Modèle du sous-processus «4- Envoyer formulaire et lettre d'information»

5.5.7.7 Modèle du ss-pm 5- Réceptionner projet

Ce ss-pm est activé lorsque la secrétaire commence à recevoir les demandes de

subventions des EE et CS pour les projets proposés.
Si le projet proposé émane d'un établissement d'enseignement (EE), il doit
nécessairement être approuvé par la CS et par la DR concernées.
Si le projet proposé émane d'une commission scolaire (CS), il doit nécessairement être
approuvé par la DR concernée.
La DAS ne gère pas les activités d'approbation des CS et des DR, ni comment ces
activités sont menées. Elle s'intéresse seulement aux avis d'approbations émis. Les
projets non approuvés par la CS et par la DR ne sont pas pris en compte. Ces dernières
ont la charge d'informer le demandeur du résultat de leur activité d'approbation.
Au cours de ce ss-pm, la secrétaire appose la date de réception sur la demande, met à
jour son registre des projets (liste sous format Excel contenant les références du
demandeur, le titre du projet, la subvention demandée et la date de réception). Ensuite,
elle fait une copie de la demande qu'elle envoie au professionnel de la DAS pour
analyse.

190 de 273
 Acteur Enchaînements et produits (

Projet EE Demande
Établissement
proposé d'approbation
U001 D02 P01 AC01 d'enseignement

Commission
\ Approuver
Z Demande Projet CS
UO01_D02_P01_AC02 scolaire (CS) d'approbation proposé
projet CS

Approbation

Direction régionale Approuver

UO01_D02_P01_AC03
(DR)

7
5.1- Mettre date de réception 5.2- Mettre à jour registre 5.3- Photocopier projet
UO01_D02_P01_AC0B Secrétaire sur la demande des projets reçu

Registre des projets (

Responsable du Liste des projets

UO01 D02 P01 AC07
programme reçus

Copie projet reçu

UO01 D02 P01 AC09 Professionnel

Figure 34 Modèle du sous-processus «5- Réceptionner projet»

191 de 273
5.5.7.8 Modèle du ss-pm 6- analyser projet

Ce ss-pm est activé lorsque le professionnel de la DAS reçoit la copie de la demande de

subvention (projet proposé).
Si le projet est jugé non conforme aux critères d'admissibilité, le professionnel rédige un
avis de non-conformité qu'il envoie à la responsable du programme de soutien, au
demandeur, à la CS et à la DR dont relève le demandeur. Un tel projet ne sera pas
soumis au comité d'évaluation.
Si le projet proposé est jugé conforme, le professionnel élabore un rapport d'analyse sur
le projet. Ce rapport constitue un résumé de la demande et des différents documents
qui peuvent l'accompagner. Il donne une description sommaire du projet, de ses
objectifs, des moyens prévus pour le mettre en œuvre, du délai de réalisation ainsi que
le montant de subvention demandé. Ce rapport est soumis au comité d'évaluation qui
approuve ou refuse la subvention demandée. Une copie de ce rapport est également
envoyée à la responsable du programme à titre d'information.
Le professionnel reçoit par la suite, l'avis du comité d'évaluation.
Quel que soit le contenu de cet avis (acceptation ou refus), le professionnel en envoie
une copie à la responsable du programme de soutien.
Si l'avis est négatif, le professionnel envoie une copie de cet avis au demandeur, à la
CS et à la DR dont relève le demandeur.
Si l'avis est favorable, le professionnel inscrit le projet concerné dans la liste des
subventions. Cette liste est alors envoyée à la responsable du programme de soutien et
aux DR, pour information, et au PM « Gestion du budget » qui procède alors à l'envoi
des chèques aux demandeurs acceptés.

192 de 273
UOO1DO2P01ACO3

Figure 35 Modèle sous-processus «6- analyser projet»

193 de 273
5.5.7.9 Modèle du ss-pm 7- Élaborer synthèse des bilans

Ce ss-pm est activé lorsque le professionnel de la DAS reçoit les bilans des projets
subventionnés. Il élabore alors une synthèse de l'ensemble des bilans. Cette synthèse
décrit sommairement les projets réalisés, leurs objectifs, les résultats atteints et les
recommandations émises. Cette synthèse est alors envoyée à la responsable du
programme, aux partenaires du Ministère, aux DR, aux CS et aux EE. L'objectif étant de
chercher à généraliser les bonnes pratiques dans le domaine de l'éducation des EHDAA
(Élèves handicapés ou en difficulté d'adaptation et d'apprentissage).

Code acteur ou PM Acteur Enchaînements et produits du sous-processus 7- Élaborer la synthèse des bilans

Établissement
UO01_DQ2_P01_AC01 d'enseignement Bilan

Commission scolaire Synthèse des

UO01 D02_P01_AC02 (CS)

Synthèse des
Direction régionale bilans
UO01.D02.P0t.AC03
(DR)

,7.1- Réceptionner bilan ,7.2- Rédiger projet de synthèse 7.3- Envoyer synthèse des bilans
UO01 D02_P01_AC09 Professionnel

projet de
Responsable du synthèse des
UO01 D02_P01_AC07
programme

Partenaire du
UO01 D02_P01_AC06
Mlnstère

Figure 36 Modèle sous-processus «7- Élaborer synthèse des bilans»

194 de 273
5.5.7.10 Modèle du ss-pm 8- Élaborer statistiques

Ce ss-pm est activé lorsque le professionnel de la DAS a émis la synthèse des bilans.
Le professionnel élabore des statistiques concernant les projets reçus, les projets
acceptés, ceux refusés ainsi que l'état des subventions accordées.
Ces états statistiques sont alors envoyés à la responsable du programme de soutien.
La figure, qui suit, donne une illustration de du modèle de ce ss-pm.

Code acteur ou PH Acteur Enchaînements et produits du sous-processu 8-État orerlesstitistiqu

7.1- Élaborer liste des 7.2-Élaborer liste des projets 7.3-Élaborer liste des fc7.4-Élaborer état des
UO01.D02.P01.AC09 Professionnel projets par type acceptés projets refusés subventions

1 1 i

Responsable du État des

UO01.D02.P01.AC07 Projets par type Projets acceptés projets refusés
programme subventions

Figure 37 Modèle sous-processus «8- Élaborer statistiques»

Comme pour le modèle global, les modèles des ss-pm ont été présentés et validées par
les intervenants de l'unité organisationnelle (la responsable du programme, le
professionnel qui gère les demandes et la secrétaire qui gère l'envoi et la réception des
demandes). Suite à cette validation, nous avons établi le diagnostic de la situation
actuelle; ce qui est l'objet de la prochaine section.

195 de 273
 5.5.8 Pose du diagnostic

Cette étape a pour but d'analyser l'information sur le PM objet qui a préalablement été
recueillie puis synthétisée dans les modèles (Figure 22 à Figure 37), dans la fiche
d'identification des problèmes (Tableau 35) et dans les tableaux des critères d'efficacité
(Tableau 33) et d'efficience (Tableau 34).
Pour ce faire, nous avons complété la fiche d'identification des problèmes (Tableau 36)
car les problèmes sont au cœur de l'activité de diagnostic. D'une part, comme nous en
avons discuté au chapitre 2, ils sont à l'origine du projet de modélisation des processus
métier. D'autre part, les activités de collecte de l'information et de modélisation avaient
comme important objectif de mener à l'identification des problèmes du PM objet.
Nous avons déterminé, pour chaque problème identifié, son impact sur le PM objet.
Cela permet au demandeur de déterminer si un problème est suffisamment important
pour qu'on lui accorde une attention particulière et de s'attaquer d'abord aux problèmes
ayant des impacts importants plutôt qu'à ceux dont les impacts sont négligeables.
Le résultat de cette étape est décrit dans le Tableau 36, ci-après.

Liste des problèmes, causes et impacts Date: 2005-02-10

Direction de
Unité
l'adaptation scolaire Code unité : U01
organisationnelle
(DAS)
Suivi des déficiences
Domaine et évaluation des Code domaine : U01_D02
programmes
Programme de
soutien à la
recherche et au
Processus métier Code processus : UO01_D02_P01
développement en
adaptation scolaire
(SoReDAS)

196 de 273
Énoncé du problème Impact

Formulation non
• Projets refusés
standardisée des
Différentes (probablement à
demandes conduisant
interprétations du Responsable du tort).
à des interprétations
contenu du formulaire programme • Augmentation du
différentes des textes
de demande délai de traitement
rédigés par le
demandeur. des demandes
L'accès aux dossiers
papier des
demandeurs n'est pas • Insatisfaction de la
Difficulté de répondre efficace (temps de clientèle.
rapidement aux recherche, mauvais • Génération de
Secrétaire
sollicitations des classement, absence nombreux appels
demandeurs d'employé, dossier et relances de la
non à portée de main, part de la clientèle.
etc.).

• Masse importante de • Risque de fournir

documents reçus. une information
erronée à cause
Difficulté de faire une
• Nombre de d'une réponse
vérification et un suivi
Professionnel ressources approximative.
rigoureux des
insuffisantes (3
demandes
personnes pour • Surcharge de
gérer le programme travail.
de soutien).
Absence d'indicateur
dans le dossier du • Réponse
• Responsable du demandeur. On se approximative.
Difficulté de connaître
programme base souvent sur la • Augmentation du
l'état courant d'une
• Professionnel mémoire individuelle délai de réponse.
demande
• Secrétaire pour fournir une • Insatisfaction de la
réponse au clientèle.
demandeur.

197 de 273
 • Absence de
statistiques
• Indicateurs de
détaillées et de
gestion produits
tableaux de bord.
moins pertinents.
Les statistiques qui
existent sont
Difficulté de cerner les sommaires et
Responsable du
résultats des travaux réalisées via des
programme outils élémentaires • Impossibilité de
de la DAS
tels que Excel. savoir quels sont
• Absence ceux qui n'ont
d'information sur les jamais participé
EE ou CS qui n'ont afin de chercher,
jamais formulé de éventuellement, le
demandes. pourquoi.
• Délai de la poste.
• Nombreux échanges
téléphoniques ou par
courriel entre le • Non-respect des
demandeur et la délais.
DAS avant de cerner
Arrivée tardive de • Responsable du
l'information • Augmentation de la
plusieurs demandes programme
demandée. charge de la
(au-delà du délai fixé • Professionnel
• Nombreuses pièces secrétaire (pour
par la DAS) • Secrétaire
jointes au formulaire répondre aux
de demande. sollicitations des
• Aucune contrainte clients)
obligeant le
demandeur à
respecter le délai.

198 de 273
 Les mises à jour et les
• Peut conduire au
rectifications
rejet d'une
envoyées par le
demande par le
demandeur sont
comité
Erreurs fréquentes lors • Responsable du transcrites
d'évaluation.
de la transcription des programme manuellement dans le
mises à jour • Professionnel formulaire original.
Cette transcription • Augmentation de la
entraîne souvent des charge des
erreurs et peut parfois ressources de la
être oubliée. DAS.
• L'information sur les
• Nombreux
• Responsable du changements n'est
Difficulté d'avoir une partenaires non
programme pas toujours
liste à jour des EE des contactés.
disponible.
CS et des partenaires • Professionnel • Nombreux retours
• Secrétaire • Mise à jour manuelle
de la poste.
et occasionnelle.
• Un demandeur
peut soumettre un
projet déjà refusé.
• Un demandeur
peut recevoir
plusieurs fois des
subvenions au
détriment d'un
autre. Ceci peut
avoir lieu lorsqu'il y
Difficulté de consulter Dossiers sous format a plus de
Responsable du demandes
l'historique des
programme papier. acceptables que le
demandes
budget alloué.
Dans un tel cas, on
aimerait privilégier
celui qui n'en a
jamais bénéficié.
• Risque de
discrimination
(involontaire) dans
l'octroi des
subventions.
Tableau 57 Liste des problèmes, leurs causes probables et leurs impacts.

La fiche, ci-dessus, a été présentée à la responsable du programme et aux autres

ressources affectées au PM objet qui l'ont validée. Cette validation, nous permet de
débuter la phase d'analyse dont le but principal est la modélisation du nouveau PM.

199 de 273
 5.6. La phase d'analyse

La phase d'analyse a pour but principal de traduire le diagnostic réalisé sous forme
d'objectifs clairement formulés en proposant des solutions visant l'optimisation du
processus objet. Les résultats du diagnostic (phase précédente) ont permis de
circonscrire les causes des problèmes identifiés. Il est donc normal d'entreprendre la
conception des modèles du PM cible en cherchant à éliminer ces causes.
La démarche proposée décompose la phase d'analyse en quatre étapes. Après avoir
planifié le travail à effectuer, l'analyste propose des solutions d'amélioration du PM objet
qu'il soumet à l'approbation des décideurs. Ces derniers analysent les solutions
proposées et en choisissent celle qui répond à leurs besoins. La solution choisie fera
ensuite l'objet de modélisation afin de montrer la configuration du PM objet transformé.
Les étapes proposées pour mener cette phase sont :
• Planification de l'analyse;
• Proposition des solutions;
• Élaboration des nouveaux modèles du PM objet;

• Présentation du rapport d'analyse.

5.6.1 Planification de l'analyse

5.6.1.1 Formation de l'équipe

Unil ; '.
Ressource 12 F
administrative ) '"'''''''" ";'!
Volontairement
R1 DAS Gestionnaire Valider les objectifs
non fournies
Fournir les informations
Responsable du
R2 DAS sur le PM objet et valider
programme
les biens livrables
Fournir les informations
Responsable du sur le PM « Gestion du
R3 DAS
budget budget » et valider les
biens livrables
Chargé de projet Recueillir les besoins et
A.S (Ali Saadi) Laval
et analyste modéliser
Tableau 58 Ressources affectées au projet

12
Les noms et coordonnées des personnes qui ont participé à cette étude ont été masqués pour des raisons de
confidentialité.
200 de 273
5.6.1.2 Echéancier des travaux

Le planning des travaux du diagnostic qui a été établi, d'un commun accord avec les
participants, est le suivant :

Activité Date début Date fin Responsable Participants

Planification de l'analyse 2005-11-07 2005-11-07 A.S R2, R3

Proposition des solutions 2005-11-07 2005-11-22 A.S R2, R3

Modélisation du nouveau PM
2005-12-23 2005-12-03 A.S R2, R3
objet

R1, R2, R3,

Présentation des résultats 2005-12-05 2005-12-05 A.S
R4,R5
Tableau 59 Echéancier des travaux

Une fois la planification de la phase d'analyse réalisée et validée par la responsable du

programme et ses collaborateurs, nous pouvons passer à l'étape de proposition des
solutions visant à résoudre les problèmes énoncés lors de la phase du diagnostic.

5.6.2 Proposition des solutions

L'objectif de cette étape est de proposer des solutions en fonction des objectifs de la
demande décrits dans la section 4.4.2 (Clarifier la demande), des caractéristiques du
PM objet identifiées dans les sections 4.5.4 [Identifier les processus métier), 4.5.5
(Définir la frontière du processus métier objet) et 4.5.6 (Modéliser le contexte du PM
objet) et du diagnostic établi (cf. section 4.6.10). Ainsi, pour la recherche de solutions
visant l'amélioration du PM objet, nous avons repris le Tableau 36 qui synthétise les
problèmes, leurs causes et leurs impacts et nous avons essayé de trouver de quelle
manière on peut éliminer la cause d'un problème ou du moins réduire son impact, tout
en respectant les objectifs du demandeur.

201 de 273
Le résultat de cette étape est consigné dans le Tableau 60 ci-après. Il reprend le
Tableau 36 qui recense les problèmes, leurs causes et leurs impacts et auquel on
ajoute les objectifs du demandeur ainsi que les solutions proposées.

202 de 273
- - .: Éléments de solutions Date : 2005-02-10
Unité
Direction de l'adaptation scolaire (DAS) Code unité : U01
organisationnelle
Suivi des déficiences et évaluation des
Domaine Code domaine : U01_D02
programmes
Programme de soutien à la recherche et au
Processus métier développement en adaptation scolaire Code processus : UO01_D02_P01
(SoReDAS) • . •

C . b > î ! ::s • . ;
; : 1' M Causes probables j Impacts Solutions proposées
•

• Standardiser le formulaire en
le décomposant en sections
Formulation non distinctes.
Avoir la même standardisée des • Fournir avec le formulaire
• Projets refusés
interprétation du Différentes demandes une description détaillée des
(probablement à tort).
contenu de demandes interprétations du conduisant à des sections.
• Augmentation du délai
afin de réduire le taux contenu du formulaire interprétations • Utiliser le plus possible les
de traitement des
des rejets à moins de de demande. différentes des questions aux choix
demandes
20%. textes rédigés par le multiples.
demandeur. • Mettre à la disposition des
clients des exemples de
projets acceptés.
L'accès aux dossiers
papier des
demandeurs n'est • Insatisfaction de la
• Mettre en place un système
Difficulté de répondre pas efficace (temps clientèle.
Répondre de classification des
rapidement aux de recherche, • Génération de
instantanément aux demandes.
sollicitations des mauvais classement, nombreux appels et
clients. • Automatiser l'accès aux
demandeurs. absence d'employé, relances de la part de la
dossier non à portée dossiers des clients.
clientèle.
de main, etc.).

203 de 273
 • Masse importante • Risque de fournir une • Limiter ie nombre de
de documents information erronée à documents envoyés par les
reçus. cause d'une réponse clients à ce qui est
approximative. nécessaire à l'évaluation des
Difficulté de faire une
Assurer un suivi • Nombre de demandes.
vérification et un suivi
rigoureux des ressources • Surcharge de travail. • Augmenter le nombre de
rigoureux des
demandes. insuffisantes (3 ressources à la DAS.
demandes.
personnes pour • Automatiser le suivi des
gérer le demandes.
programme de
soutien).
Absence d'indicateur
dans le dossier du
• Réponse approximative. • Inscrire sur la demande les
demandeur. On se
Connaître l'état d'une Difficulté de connaître • Augmentation du délai différents états possibles et
base souvent sur la
demande à tout l'état courant d'une de réponse. cocher l'état courant.
mémoire individuelle
moment. demande. • Insatisfaction de la • Rendre accessible l'état
pour fournir une
clientèle. courant aux clients.
réponse au
demandeur.
• Absence de
statistiques • Élaborer des tableaux de
détaillées et de bord et des statistiques de
• Indicateurs de gestion
tableaux de bord. façon périodique sur les
produits moins
Les statistiques qui projets, les bilans, les
pertinents.
existent sont subventions, etc.
Mettre en valeur les sommaires et • Établir la liste des
réalisations de la DAS Difficulté de cerner réalisées via des organismes scolaires qui
et sensibiliser les résultats des outils élémentaires n'ont jamais fait de demande
l'ensemble des travaux de la DAS. tels que Excel. • Impossibilité de savoir
pour chercher le pourquoi.
organismes scolaires. • Absence quels sont ceux qui
• Établir la liste des
d'information sur n'ont jamais participé
organismes scolaires dont
les EE ou CS qui afin de chercher,
les demandes sont toujours
n'ont jamais éventuellement, le
refusées et chercher le
formulé de pourquoi.
pourquoi.
demandes.

204 de 273
 • Délai de la poste.
• Nombreux
échanges
téléphoniques ou
• Prévoir un mode d'envoi plus
par courriel entre le
performant.
demandeur et la
• Non-respect des délais. • Sensibiliser les organismes
DAS avant de
Arrivée tardive de scolaires sur l'impact des
Respect des délais de cerner l'information
plusieurs demandes • Augmentation de la retards d'envoi sur le
soumissions des demandée.
(au-delà du délai fixé charge de la secrétaire traitement de leur demande.
demandes. • Nombreuses pièces
par la DAS). pour répondre aux • Utiliser les possibilités des
jointes au
sollicitations des clients. technologies de l'information
formulaire de
demande. et des communications.
• Aucune contrainte
obligeant le
demandeur à
respecter le délai.
Les mises à jour et
les rectifications
envoyées par le • Peut conduire au rejet
demandeur sont d'une demande par le
Réduire le taux Erreurs fréquentes Permettre au demandeur de
transcrites comité d'évaluation.
d'erreur de lors de la faire lui-même la mise à jour
manuellement dans
transcription des transcription des le formulaire original. en utilisant par exemple le
• Augmentation de la
mises à jour. mises à jour. Cette transcription web.
charge des ressources
entraîne souvent de la DAS.
des erreurs et peut
parfois être oubliée.

205 de 273
 Utiliser l'information disponible
• L'information sur
dans un PM dénommé
les changements
Avoir une liste à jour Difficulté d'avoir une • Nombreux partenaires GDUNO (Gestion des
n'est pas toujours
des organismes liste à jour des EE, non contactés. Dossiers UNiques des
disponible.
scolaires et des des CS et des • Nombreux retours de la Organismes) qui existe au
• Mise à jour
partenaires. partenaires. poste. Ministère. Ce PM est à jour et
manuelle et
constitue la source la plus
occasionnelle.
fiable.
• Un demandeur peut
soumettre un projet déjà
refusé.
• Un demandeur peut
recevoir plusieurs fois
des subvenions au • Prévoir un mécanisme de
détriment d'un autre. consultation selon différents
Ceci peut avoir lieu critères.
Difficulté de consulter
Cerner les demandes • Dossiers sous lorsqu'il y a plus de • Organiser la classification et
l'historique des
dans le temps. format papier. demandes acceptables l'archivage des demandes.
demandes.
que le budget alloué. • Permettre la recherche et
Dans un tel cas, on l'accès aux demandes selon
aimerait privilégier celui la période désirée.
qui n'en a jamais
bénéficié.
• Risque de discrimination
(involontaire) dans
l'octroi des subventions.

Tableau 60 Éléments de solutions.

206 de 273
 Une fois les éléments de solutions définis, l'équipe de décision (responsable du
programme et professionnel de la DAS) ont analysé les choix proposés et ont
sélectionné ceux qui constituent, à leurs yeux, la solution à retenir et à base de laquelle
seront conçus, lors de prochaine étape de l'étude, les nouveaux modèles du PM objet.
Le tableau qui suit montre les solutions retenues :

Fiche 07 Solutions retenues Date : 2005-02-10

. • • • . • • • • • • . • ; ; . . • • ' •• • • • • •

Unité
Direction de l'adaptation
Code unité : U01
organisationnelle scolaire (DAS)
Suivi des déficiences et
Domaine Code domaine : U01_D02
évaluation des programmes
Programme de soutien à la
recherche et au
Processus métier Code processus : UO01_D02_P01
développement en adaptation
scolaire (SoReDAS)
Objectifs

• Standardiser le formulaire en le
Avoir la même
décomposant en sections
interprétation du
Différentes interprétations du distinctes.
contenu de demandes
contenu du formulaire de • Fournir avec le formulaire une
afin de réduire le taux
demande. description détaillée des sections.
des rejets à moins de
• Utiliser le plus possible les
20%.
questions aux choix multiples.
Répondre Difficulté de répondre
• Automatiser l'accès aux dossiers
instantanément aux rapidement aux sollicitations
des clients.
clients. des demandeurs.
Assurer un suivi Difficulté de faire une
rigoureux des vérification et un suivi Automatiser le suivi des demandes.
demandes. rigoureux des demandes.
Connaître l'état d'une
Difficulté de connaître l'état • Rendre accessible l'état courant aux
demande à tout
courant d'une demande. clients via le web.
moment.
• Élaborer des tableaux de bord et
des statistiques de façon périodique
sur les projets, les bilans, les
Mettre en valeur les subventions, etc.
réalisations de la DAS Difficulté de cerner les • Automatiser la production de
et sensibiliser résultats des travaux de la rapports (liste des organismes
l'ensemble des DAS. scolaires qui n'ont jamais fait de
organismes scolaires. demande, la liste des organismes
scolaires dont les demandes sont
toujours refusées, etc.).

207 de 273
 • Prévoir un mode d'envoi plus
performant.
• Sensibiliser les organismes
scolaires sur l'impact des retards
Respect des délais de Arrivée tardive de plusieurs
d'envoi sur le traitement de leur
soumissions des demandes (au-delà du délai
demande.
demandes. fixé par la DAS).
• Utiliser les possibilités des
technologies de l'information et des
communications.

Réduire le taux
Permettre au demandeur de faire lui-
d'erreur de Erreurs fréquentes lors de la
même la mise à jour en utilisant par
transcription des transcription des mises à jour.
exemple le web.
mises à jour.
Utiliser l'information disponible dans
Avoir une liste à jour un PM dénommé GDUNO (Gestion
Difficulté d'avoir une liste à
des organismes des Dossiers UNiques des
jour des EE, des CS et des
scolaires et des Organismes) qui existe au Ministère.
partenaires.
partenaires. Ce PM est à jour et constitue la
source la plus fiable.
Automatiser la recherche et l'accès
Cerner les demandes Difficulté de consulter
aux demandes selon la période
dans le temps. l'historique des demandes. désirée.

Tableau 61 Solutions retenues.

Pour la modélisation du nouveau PM objet, nous présentons d'abord, un modèle global

du nouveau PM objet et de ses sous-processus (cf. Figure 22) puis un modèle détaillé
de chacun des nouveaux sous-processus (cf. Figure 23 à Figure 45).

5.6.3 Élaboration des nouveaux modèles du PM objet

L'objectif de cette étape est d'élaborer les nouveaux modèles du PM objet en fonction
de la solution retenue et de distinguer, à travers ces nouveaux modèles, les parties à
automatiser (PM cible) de celles qui ne le seront pas.
La modélisation du nouveau PM objet a été réalisée selon le même principe que celui
énoncé dans la section 4.6.7 (Modéliser le PM objet). D'abord, un modèle global du
nouveau PM objet et de ses nouveaux sous-processus puis un modèle détaillé de
chacun des nouveaux sous-processus.

208 de 273
 Avant de dessiner ces nouveaux modèles, nous rappelons les objectifs du nouveau PM
objet, les objectifs du PM cible (partie à automatiser) ainsi que les bénéfices que peut
tirer l'organisation par la transition du PM objet vers le nouveau PM.

5.6.3.1 Objectifs du nouveau PM objet

Selon les souhaits du demandeur, le nouveau PM objet doit répondre aux objectifs
suivants :

• Alléger la tâche de préparation et d'envoi des formulaires et des lettres d'information

aux organismes scolaires (environ 9600 envois par la poste actuellement);
• Réduire le temps de traitement des demandes;
• Automatiser le maximum d'activités manuelles;
• Permettre une meilleure intégrité des données gérées;
• Permettre aux clients de connaître rapidement l'état courant de leur demande;
• Faciliter la recherche de l'information;
• Profiter des possibilités des technologies de l'information et des communications
(TIC) pour une meilleure gestion et un meilleur suivi du programme de soutien à la
recherche et au développement en adaptation scolaire;
• Favoriser le développement de nouvelles pratiques d'intervention en milieu EHDAA.

5.6.3.2 Objectifs du nouveau PM cible (partie à automatiser)

La partie à automatiser du nouveau PM objet doit contribuer à l'atteinte des objectifs

suivants :

• Éliminer les envois par la poste afin de limiter les frais reliés;

• Gérer de manière sécuritaire les données traitées;

• Réduire le temps de traitement des demandes;

• Offrir des tableaux de bord pour le suivi;

• Ne pas induire une charge de travail aux ressources de la DAS;

209 de 273
 • Utiliser les TIC pour les échanges avec les clients et les partenaires, pour la mise à
jour des demandes, la consultation et la génération de rapports;
• Être facile d'utilisation;
• Exploiter les données déjà existantes au sein du PM GDUNO au lieu de les gérer en
double au sein du PM objet de l'étude. Rappelons que le PM GDUNO emmagasine
toutes les informations relatives aux organismes scolaires et aux partenaires du
Ministère (nom organisme, type, coordonnées, courriel, responsable, etc.).

5.6.3.3 Bénéfices

Le nouveau PM objet ainsi que sa partie candidate à une automatisation apporteront à

l'organisation les bénéfices suivants :
• Réduction du temps des traitements des opérations de la DAS : La diffusion
électronique des formulaires, des lettres d'information, des avis d'approbations, etc.
réduit considérablement le temps de préparation et d'envoi par la poste;
• Réduction du temps de recherche : Un système informatisé peut facilement offrir un
moyen de recherche rapide et multicritères;
• Réduction des appels téléphoniques et par conséquent, réduction de la charge des
ressources de la DAS : Les clients peuvent consulter, en ligne, l'état de leur
demande et l'historique de leurs demandes antérieures;
• Réduction des frais reliés à l'envoi par la poste;
• Conservation de l'historique des demandes dans une base de données à des fins
diverses (statistiques, études, etc.);
• Diminution des risques d'erreurs (dans les envois, les mises à jour des dossiers, les
réponses aux clients, etc.) inhérents à la gestion manuelle actuelle;
• Suppression de la charge considérable due à la gestion locale et manuelle de la liste
des organismes scolaires et des partenaires : Le PM GDUNO dispose de toute
l'information nécessaire.
• Plus grande qualité de l'information.
• Les informations permettant le traitement des demandes seront conservées
électroniquement, ce qui constituera une mémoire organisationnelle pouvant être
exploitée par les employés futurs;

210 de 273
 • La Direction de l'adaptation scolaire pourra exploiter les données concernant les
établissements d'une façon efficace et efficiente ce qui permettra de répondre aux
autres secteurs du Ministère, aux partenaires et aux organismes scolaires dans de
meilleurs délais;
• L'intégrité et la qualité des données sont maintenues et protégées par la technologie
ORACLE adoptée comme norme au sein du Ministère.

5.6.3.4 Modèle global du nouveau PM objet

L'objectif de ce modèle est de montrer l'enchaînement des activités au sein du PM objet

vu sous un aspect macroscopique sans trop de détails, ainsi que les échanges de ce
dernier, en termes d'entrées et de sorties (inputs/outputs), avec son environnement.
Pour construire ce modèle, nous nous sommes basés sur les résultats de la phase du
diagnostic, notamment la liste des messages échangés entre le PM objet et ses
différents acteurs, les données confinées dans des BD et/ou des fichiers, les
informations sur les composantes du PM objet, l'information sur les performances
souhaitées et particulièrement sur les problèmes énoncés, leurs causes et leurs
impacts. Nous avons également tenu compte des solutions proposées et adoptées par
les intervenants de l'unité organisationnelle, des objectifs du nouveau PM objet et des
bénéfices escomptés.
Après plusieurs rencontres, l'équipe de travail s'est finalement mise d'accord sur la
décomposition du nouveau PM objet en plusieurs sous-processus, comme suit :
• Élaborer (par la responsable du programme) la lettre d'information avisant les
organismes scolaires du début de la réception des propositions de projets (Manuel).
Nous remarquons, qu'à la différence de l'ancien PM objet, ce ss-pm ne s'occupe
plus de l'élaboration du formulaire de demande. Ce dernier sera géré par le ss-pm
« Gérer les demandes ».
• Saisir (par la secrétaire) la lettre d'information (Manuel). Une fois validée par la
responsable du programme, cette lettre sera enregistrée dans un registre des lettres
afin qu'elle soit accessible au ss-pm « Envoyer la lettre d'information » qui procède à
un envoi automatisé;

211 de 273
• Valider (par la responsable du programme) les données saisies dans la lettre
d'information (Manuel);
• Envoyer (par la secrétaire) la lettre d'information aux organismes scolaires (CS et
EE) et aux DR (Automatisé). Ce ss-pm, entièrement manuel dans l'ancien PM objet
et qui constituait un problème majeur à cause du volume (9600 envois par la poste),
des coûts inhérents, des erreurs dans les adresses, etc., sera entièrement
automatisé grâce à l'utilisation du courriel mais, surtout, grâce au PM GDUNO qui
fournira automatiquement, toutes les données, sur les organismes scolaires et les
partenaires du Ministère, que l'ancien PM objet gère à travers des listes manuelles
de qualité douteuse;
• Gérer les demandes (par le professionnel de la DAS) (Automatisé). Ce ss-pm
s'occupera de toutes les activités relatives aux demandes, depuis leur réception
jusqu'à l'aboutissement de leur évaluation et l'envoi des subventions;
• Gérer les bilans (par le professionnel de la DAS) (Automatisé). Ce ss-pm a pour
objectif de gérer toutes les activités se rapportant aux bilans envoyés par les
demandeurs subventionnés;
• Exploiter la BD (par le professionnel de la DAS) (Automatisé). Dans ce ss-pm, nous
considérons toutes les exploitations classiques d'une BD (extraction de données,
élaborations de rapports statistiques, de tableaux de bord, d'état de suivi, etc.).

D'après cette décomposition, le lecteur notera que nous n'avons pas prévu, dans le
nouveau PM objet, un ss-pm important; à savoir le ss-pm « Gérer la BD » (mots de
passe, archivage, copies de sécurité, contrôles des accès, etc.). En effet, le Ministère
dispose de systèmes dits « systèmes serveurs », indépendants des applications
informatiques et dont la fonction principale est de gérer toutes les opérations relatives
aux BD et aux accès des usagers. Les PM automatisés n'ont pas à se préoccuper de
ces aspects. Cette politique permet, au Ministère, une grande réutilisation de services
déjà mis en place et qui sont communs à la quasi-totalité des applications informatiques.
Dans la Figure 38, qui suit, nos donnons une illustration du modèle global du nouveau
PM objet. La description de chaque ss-pm de ce modèle est fournie dans les prochaines
sections. Les parties grises de cette figure et de toutes celles qui suivent indiquent les
parties candidates à une automatisation.

212 de 273
 produits du nouveau PU objet

UO01 MB POI «01

pn
\

DOOIIKB POI ACO! Li8

Direct» ii|M(
« X I 1 9 ! POI ACM

1- Élaborer lettre 2- Saisir lettre 3-Vaiderlettre

-• y
d'tnfomation «omitioii «mtwi

irai coi POI m (Mi Muta

PWGesSordu
UO01 DO! POI a
M|er

PHGDUNO

UOOI DO! « I « M

Figure 38 Modèle global du nouveau PM objet SoReDAS

213 de 273
5.6.3.5 Modèles des ss-pm du nouveau PM objet

Une fois le modèle global soumis aux divers intervenants et validé, nous avons procédé
à l'élaboration des modèles des sous-processus métier (ss-pm) composant le nouveau
PM objet. Ces sous-processus sont :
• Élaborer lettre d'information;
• Saisir lettre d'information;
• Valider lettre d'information;
• Envoyer lettre d'information;
• Gérer les demandes;
• Gérer les bilans;
• Exploiter la BD.

Les modèles de ces ss-pm sont schématisés dans les figures 39 à 45.

5.6.3.6 Modèle du ss-pm 1- Élaborer lettre d'information

Ce ss-pm a pour but l'élaboration de la lettre d'information (par la responsable du

programme) destinée à informer les organismes scolaires et les DR du début de la
soumission des demandes de subvention pour les projets à réaliser.
Ce ss-pm diffère de son équivalent, dans l'ancien PM objet, par le fait qu'il ne gère plus
le formulaire de soumission des demandes. Ce dernier sera élaboré de manière
standard lors de la conception (au sens informatisation) du ss-pm « Gérer les
demandes » du nouveau PM objet. Il constituera une page interactive permettant au
demandeur de formuler et d'enregistrer directement sa demande. Ainsi, seront éliminés
tous les envois effectués actuellement par voie postale (environ 9600 envois).
La forme du formulaire et son contenu, ne sont pas dans la portée de ce mémoire car ils
relèvent de l'informatisation proprement dite du ss-pm « Gérer les demandes ».

214 de 273
 La Figure 39, ci-après, donne une illustration du modèle de ce ss-pm :
Co^te.^ Acteur Enchaînements et prod uits du sous-processus 1- Élaborer lettre d'information

Responsable du 1.1- Élaborer lettre d'information

UO01_D02_P01_AC07
programme

Sous-processus
UO01_D02_P01_SSPM02 "2- Saisir lettre
d'information"
Lettre âinfbmutlor

,———
]
Budget du
UO01_D02_P01_AC05 PM "Gestion du budget" programme

Figure 39 Modèle du ss-pm « 1- Élaborer lettre d'information »

5.6.3.7 Modèle du ss-pm 2- Saisir lettre d'information

L'objectif de ce ss-pm est rendre sous forme électronique la lettre d'information produite
par le sous-pm «7- Élaborer lettre d'information». La secrétaire procède à sa saisie et à
son enregistrement, sous format Word, dans un registre de lettres. Une copie papier est
envoyée à la responsable du programme pour validation.
La Figure 40, suivante, donne une illustration du modèle de ce ss-pm :

Code acteur ou PM Acteur Enchaînements et produit i du sou '-UHWP58U8 2 Sdisif lettrt dïnfomut on

1 —i
Lettre d'information
Responsable du Lettre û'intomwrtlon a valider
UO01_D02_P01_AC07
programme

"1 2.2- Enregistrer lettre

2.1- Saisir lettre d'information
UO01_D02_P01_AC08 Secrétaire d'information

1 Registre des j —
l des lettres l

Figure 40 Modèle du ss-pm « 2- Saisir lettre d'information »

215 de 273
5.6.3.8 Modèle du ss-pm 3- Valider lettre d'information

L'objectif de ce ss-pm est de valider le contenu de la lettre d'information. Il est activé par
l'envoi, de la part de la secrétaire, d'une copie du contenu saisi sous forme électronique
de la lettre d'information. La responsable du programme procède aux corrections
éventuelles et renvoie à la secrétaire le document avec les corrections éventuelles.
La Figure 41, suivante, donne une illustration du modèle de ce ss-pm :

Code acteur ou PM Acteur !•«!!*.»:,••• -,.,;.•,-»:» •! i ,.: ! <Mv;n.-,.,.^.- • <•/ Srf : ï ™ . ; - ! W ^ w v ;„•

Lettre d'in ormation Lettre d'Information

à va der /alidée
UO01_D02_P01_AC08 Secrétaire
^^—,—«- -—

Responsable du 3.1-Valider lettre d'information

UO01_D02_P01_AC07
programme

Figure 41 Modèle du sous-processus «3- Valider lettre d'information»

5.6.3.9 Modèle du ss-pm 4- Envoyer lettre d'information

Ce ss-pm est activé lorsque la secrétaire reçoit la lettre d'information validée par la
responsable du programme. Elle procède aux corrections éventuelles et met à jour son
registre des lettres.
Dans ce nouveau ss-pm, l'envoi de la lettre ne se fait plus via la poste. La secrétaire
utilise les informations sur les organismes scolaires et les DR, offertes par le PM
GDUNO, pour effectuer son envoi par l'intermédiaire d'un courriel automatisé. Cette
façon de faire génère un gain considérable, en temps et en frais, par rapport à la façon
de faire actuelle (gestion manuelle d'une liste d'environ 9600 entrées avec tout ce que
cela comporte comme inconvénients).
La Figure 42, qui suit, donne une illustration du modèle de ce ss-pm :

216 de 273
 Acteur

UO01.D02.P0I.AC07

Informations sur te EE, [

UO01_D02_P01_AC10 PM GDUNO CS. DR et partenaires du (
Ministère V^

Établissement
UO01_D02_P01_AC01
d'enseignement (EE)

UO01_D02_P01_AC02 Commission scolaire (CS)

Lettre (fWomation
UOO1_D02_PÛ1_AC03 Direction régionale (DR)

Figure 42 Modèle du sous-processus «A- Envoyer lettre d'information»

5.6.3.10 Modèle du ss-pm 5- Gérer les demandes

Ce ss-pm constitue le cœur du nouveau PM objet et sera fortement automatisé. Son

objectif est de rendre automatiques, les activités causant le plus de problèmes ou
générant le plus de frais ou de perte de temps, selon la façon de faire dans l'ancien PM
objet, notamment l'envoi, par la poste, du formulaire et des propositions de projets, la
mise à jour manuelle des demandes, les erreurs de la transcription des mises à jour, les
communications multiples avec les clients désirant s'informer sur l'état de leur demande,
le suivi des demandes, la gestion de l'historique des projets, l'accès à l'information, etc.
(cf. Tableau 57 Liste des problèmes, leurs causes probables et leurs impacts.).
L'automatisation de ce ss-pm permet au demandeur d'enregistrer sa demande, en ligne,
dans un formulaire standard présenté sous forme d'une interface interactive dont la

217 de 273
structure et le contenu seront définis lors de l'informatisation proprement dite de ce ss-
pm (l'informatisation est en dehors de la portée de notre mémoire).

Le ss-pm « 5-Gérer les demandes » est activé lorsqu'un établissement d'enseignement

(EE) ou une commission scolaire (CS) saisit sa proposition de projet. Il est composé des
unités de tâches suivantes :
• « 5.1-Réceptionner projet» (Automatisé): Lorsque le demandeur formule sa
demande et l'enregistre, cette dernière est emmagasinée dans la BD. Les
approbateurs (CS ou DR) peuvent, alors, consulter la liste des demandes en attente
d'être approuvées et émettre leur approbation (accepté ou refusé). Des champs
doivent donc être prévus dans le formulaire permettant l'enregistrement de cette
approbation;
• « 5.2-lmprimer projet » (Automatisé) : Le professionnel de la DAS utilise cette unité
de tâche pour imprimer les projets acceptés par les approbateurs afin de valider leur
conformité avec les critères d'admissibilité communiqués aux EE, aux CS et aux DR,
dans la lettre d'information.
Rappelons que, dans la politique de la DAS, les projets refusés par les CS ou par les
DR ne sont pas pris en compte. Toutefois, ces projets sont conservés dans la BD et
demeurent disponibles aux demandeurs afin de leur permettre d'utiliser une
ancienne demande, comme base, pour en formuler une nouvelle sans avoir à
ressaisir, par exemple, des données invariantes dans le temps, pour le demandeur
ou celles nécessitant des adaptations mineures, etc.;
• « 5.3-Vérifier la conformité » (Manuel) : Une fois, un projet imprimé, le professionnel
de la DAS vérifie la conformité du projet proposé par rapport aux critères
d'admissibilité.
• Le résultat de cette vérification (conforme, non-conforme) est alors utilisé pour
alimenter l'unité de tâche « 5.4-lnscrire l'état de conformité » qui suit;
• « 5.4-lnscrire l'état de conformité » (Automatisé) : Le professionnel de la DAS utilise
cette unité de tâche pour inscrire, pour la demande concernée, l'état de conformité
résultant de l'activité précédente.
• Si ce résultat est « non-conforme », le professionnel de la DAS exécute alors l'unité
de tâche « 5.5-Rédiger avis de non-conformité ».

218 de 273
Si le résultat est « conforme », le professionnel de la DAS exécute alors l'unité de
tâche « 5.7-1nscrire analyse du projet »;
« 5.5-Rédiger avis de non-conformité » (Automatisé) : Le professionnel de la DAS
utilise cette unité de tâche pour rédiger un avis de non-conformité expliquant,
brièvement, les raisons ayant conduit à un tel jugement. Cet avis est enregistré dans
la BD en lien avec la demande concernée et sera utilisé par l'unité de tâche « 5.6-
Envoyer avis de non-conformité»;
« 5.6-Envoyer avis de non-conformité » (Automatisé) : Le professionnel de la DAS
utilise cette unité de tâche pour envoyer les avis de non-conformité à la responsable
du programme, à l'organisme scolaire concerné (EE ou CS), à la CS dont dépend
l'organisme scolaire (si le demandeur est un EE) et à la DR dont dépend
administrativement l'organisme scolaire.
Le PM GDUNO est utilisé dans cette unité de tâche pour fournir les informations sur
les destinataires (nom, prénom, fonction, courriel, etc.). Ces informations étaient
gérées manuellement dans l'ancien PM objet et les envois se faisaient via la poste;
« 5.7-lnscrire analyse du projet » (Automatisé) : Le professionnel de la DAS utilise
cette unité de tâche pour inscrire un rapport sommaire constituant son analyse pour
un projet jugé conforme aux critères d'admissibilité. Une fois son analyse enregistrée
dans la BD, il génère un rapport qu'il envoie à la responsable du programme et au
comité d'évaluation. Ce dernier utilise ce rapport pour émettre un avis favorable ou
non favorable à l'octroi d'une subvention;
« 5.8-Gérer l'avis du comité d'évaluation » (Automatisé) : Lorsque le comité
d'évaluation reçoit le rapport d'analyse, il se concerte pour émettre son avis sur le
projet concerné. À l'issue des délibérations, un membre désigné de ce comité utilise,
alors, cette unité de tâche pour inscrire l'avis (accepté, non-accepté) du comité ainsi
que le montant de la subvention accordée et la raison de non-acceptation, s'il y a
lieu. Le montant inscrit peut être nul (si projet non-accepté), inférieur ou égal à celui
demandé.
Il faut noter que la DAS ne gère ni le processus d'évaluation par le comité, ni la façon
dont les projets sont acceptés ou refusés par ce dernier ni le montant des
subventions accordées.

219 de 273
 Dès lors que le comité a inscrit son avis et le montant alloué, un courriel est généré
et envoyé à la responsable du programme, au demandeur, à sa CS et sa DR. Ce
courriel comporte, outre l'identification du demandeur et du projet proposé, l'avis du
comité d'évaluation, le montant demandé, le montant accordé et la raison de non-
octroi de subvention si le projet est rejeté par le comité d'évaluation;
• « 5.9-Générer et envoyer l'état des subventions » (Automatisé) : Pour tout projet
dont la subvention, accordée par le comité d'évaluation, est non nulle, cette unité de
tâche génère un état de subventions qui est envoyé à la responsable du programme
et au PM « Gestion du budget ». Ce dernier établit les chèques et les envoie aux
destinataires. La gestion des chèques ne relève pas de la responsabilité du PM objet
étudié.

Nous donnons dans la Figure 43, ci-après, une illustration du modèle de ce ss-pm.

220 de 273
 «ftraS

a» ;

•* ;

Figure 43 Modèle du sous-processus «5- Gérer les demandes»

221 de 273
5.6.3.11 Modèle du ss-pm 6- Gérer les bilans

Ce ss-pm a pour but de gérer les bilans des projets, élaborés par les demandeurs
auxquels une subvention a été accordée, et la synthèse établie par le professionnel de
la DAS.
Il est activé lorsque les bilans sont reçus et que le professionnel débute son rapport de
synthèse. Ce ss-pm est composé des unités de tâche suivantes :
• « 6.1-Réceptionner bilan » (Automatisé): Lorsqu'un demandeur, ayant été
subventionné, réalise son projet, il est appelé à présenter un bilan du projet réalisé.
Ce bilan énumère les résultas atteints, les difficultés rencontrées, des
recommandations, etc. Ce bilan est enregistré dans la BD via une interface
interactive qui le relie automatiquement au projet concerné (cet aspect est à détailler
lors de l'informatisation; ce qui n'est pas l'objet de ce mémoire);
• « 6.2-lmprimer bilan » (Automatisé) : Le professionnel de la DAS utilise cette unité
de tâche pour imprimer les bilans reçus à des fins de lecture et pour préparer la
synthèse; objet de la prochaine unité de tâche;
• « 6.3-Rédiger synthèse » (Manuel) : Une fois les bilans des projets imprimés, le
professionnel de la DAS rédige une synthèse de l'ensemble des bilans. Cette
synthèse constitue une compilation décrivant sommairement les objectifs, les
résultats atteints, les difficultés rencontrées et les recommandations.
La synthèse est envoyée à la responsable du programme qui la valide et la retourne
au professionnel de la DAS. Ce dernier utilise, alors, l'unité de tâche « 6.4-Saisir
synthèse » pour effectuer la saisie et l'enregistrement de la synthèse;
• « 6.4-Saisir synthèse » (Auto) : Une fois la synthèse validée par la responsable du
programme, le professionnel de la DAS procède, alors, à la saisie et l'enregistrement
de la synthèse dans la BD;
• « 6.5-Envoyer synthèse » (Auto) : Lorsque la synthèse est enregistrée dans la BD, le
professionnel de la DAS active, alors, cette unité de tâche pour effectuer l'envoi à
tous les EE, les CS, les DR et les partenaires du Ministère. L'objectif de cet envoi est
de partager les expériences réalisées, dans le cadre du soutien aux élèves EHDAA,
avec tous ceux qui oeuvrent dans le domaine de l'éducation. Encore une fois, nous

222 de 273
 utilisons les informations sur les organismes scolaires, les DR et les partenaires du
Ministère, offertes par le PM GDUNO, pour effectuer l'envoi par l'intermédiaire d'un
courriel automatisé.

La Figure 44, qui suit, donne une illustration du modèle du ss-pm «6- Gérer les bilans»:

Enchaînements et produits du sous-processus 6» Gérer les bila

UO01_D02_P01_AC01

Interface de saisie du
UO01_D02_P01_AC02 scolaire (CS) bilan CS

UO01_D02_P01_AC03 Direction régionale

(DR)

6.3- Rédiger 6.5- Envoyer

, ; , . V . i - , ; | ) i i ' » n i , j t U!,',i,
ii:>.•>••- JO.Z- li,l|.iW ,,'i.i! ,!•; ;
UO01_D02_P0t_AC09 synthèse des bilans Hsynlhtse des bilans
I I J

Responsable du Synthèse a Synthèse des

UO01_D02_P01_AC07 bilans bilans validée

Synthèse des
Partenaires du
UO01_D02_P01_AC06 bilans valida»

Informations sur les Informations sur les

UO01_D02_P01_AC10 ES, CS, DR et EE, CS, DR et
PM GDUNO
partenaires du partenaires du
Ministère (1) Ministère

Note 1 : Pour éviter de surcharger le modèle avec des flèches qui s'entrecroisent, nous avons répété l'icône BD dans ce diagramme. C'est la même BD.
Il en sera de même pour celle du PM GDUNO, lorsque nécessaire.
Note 2 : La gestion des chèques et leur envoi ne relèvent pas du PM objet étudié.

Figure 44 Modèle du sous-processus «6- Gérer les bilans»

223 de 273
5,6.3.12 Modèle du ss-pm 7- Exploiter la BD

Ce ss-pm a pour but de produire tous les rapports désirés et qui seront définis lors de la
conception du PM cible (au sens informatisation). Nous rappelons que l'objectif de ce
mémoire n'est pas de faire l'analyse et la conception du système cible, mais plutôt de
montrer les parties candidates à une automatisation. Toutefois, certains rapports sont
produits actuellement, quoique manuellement dans l'ancien PM objet, et c'est pour cela
que les nous fournissons, à titre indicatif, dans le modèle de ce ss-pm; à savoir :
• Liste des projets par type;
• Liste des projets acceptés;
• Liste des projets par refusés;
• État des subventions.

D'autres exploitations de la BD peuvent être envisagées (lors de l'informatisation) du

moment que toutes les données relatives aux projets sont emmagasinées dans la même
BD dans le nouveau PM objet.
Les rapports, produits par ce ss-pm, sont générés par le professionnel de la DAS qui les
envoie à la responsable du programme pour information. Nous pouvons, aussi, imaginer
un autre scénario pour ce ss-pm; celui d'offrir, à la responsable du programme (ou à tout
autre usager autorisé), une interface interactive qui montre la liste des exploitations
permises et générer elle-même le rapport désiré : On élimine ainsi l'activité de
génération et d'envoi par le professionnel de la DAS (gain de temps).

La Figure 45, qui suit, donne une illustration du modèle du ss-pm «7- Exploiter la BD»:

224 de 273
 Code acteur ou
Acteur Enchaînements et produits du sous-procossus 7- Exploiter la base de données
• • • _ • •

7.1-Produire Sste des 7.2-Produire liste des projets 7.3-Produire liste des 7.4-Produire état des
—• 7.5- Autres exploitations
UO01 002 P01 AC09 Profssionnel projets par type projets refusés subventions

Projets par État des Autres

UO01 D02 P01 AC07 rapports
programme type refusés subventions I

Noto 1 : Pour éviter de surcharger le modèle avec desflèchesqui s'entrecroisent et le rendre moins lisible, nous avons répété l'icône BD dans ce diagramme. C'est la même BD.

Figure 45 Modèle du sous-processus «7- Exploiter la BD»

Dans la section qui suit, nous allons aborder brièvement la conception du PM cible
(parties à automatiser). Notre but n'est pas de concevoir le système informatique de la
partie automatisée détectée dans les modèles du nouveau PM objet (cela est en
dehors de la portée du présent mémoire) mais tout simplement, de soulever une
question de taille relative aux méthodes orientées-objet; celle de savoir si elles
répondent bien au processus d'informatisation lors de la phase d'analyse (étude de
l'existant, spécification des besoins, modélisation du métier, etc.) ou bien doivent-elles
être utilisées uniquement lors de la conception proprement dite du système
informatique ? Nous allons illustrer notre point de vue en utilisant l'un des concepts
fondamentaux du paradigme orienté objet (00), à savoir les cas d'utilisation (use
cases) qui permettent, selon les auteurs ([43], [57], [80], [81], [82]) de capturer et de
structurer les besoins des utilisateurs et les objectifs correspondants d'un système.

225 de 273
5.7. Diagramme des cas d'utilisation (CU)

L'approche orientée-objet, c'est-à-dire utilisant résolument les objets dans les

techniques d'analyse et de conception, est de plus en plus utilisée. Les avantages de
cette technologie sont bien connus : réutilisation des composants logiciels (typage,
encapsulation, héritage, polymorphisme...), maintenabilité accrue des applications,
cohérence avec la vision que l'utilisateur a du système, approche décentralisée
faiblement procédurale (les objets communiquent en s'envoyant des messages). Notez
bien que tous ces avantages concernent des préoccupations de développeurs de
systèmes informatiques. Aussi et selon notre point de vue, les approches basées sur les
objets sont plus adaptées à la conception et au développement de logiciel qu'à l'analyse
et à la conception de systèmes d'information. Notamment, elles supportent mal les
aspects de capture des besoins des utilisateurs et de formalisation de ces besoins dans
un langage et des diagrammes facilement compréhensibles par l'utilisateur.
Comme annoncé à la fin de la section précédente, nous allons illustrer notre point de
vue en utilisant l'exemple des diagrammes des cas d'utilisation (CU) que nous
appliquons aux ss-pm « 5-Gérer les demandes » (Figure 43). Selon les définitions
fournies dans la littérature ([43], [57], [80], [81], [82]) les diagrammes des cas d'utilisation
se composent d'acteurs (représentés par des silhouettes) et des cas d'utilisation
. représentés par des ellipses). Les traits entre les cas l'utilisation et les acteurs
représentent les interactions. Ces diagrammes montrent les relations qui existent entre
des acteurs et des fonctionnalités du système. Ils sont utilisés tout au long du processus
de développement pour formaliser les comportements et la synchronisation des actions.
Ils peuvent définir l'état actuel d'un système ainsi que les exigences auxquelles devra
répondre le système à construire.
La Figure 46, ci-après, illustre le diagramme des CU du ss-pm « 5-Gérer les
demandes ».
Légende utilisée dans la Figure 46:
• Une ligne simple, entre un acteur et un cas d'utilisation (CU), signifie que l'acteur
émet et reçoit de l'information.
• Une flèche (-^) vers un acteur, signifie que ce dernier reçoit de l'information du CU.
• Une flèche (<•) vers un CU, signifie que l'acteur envoie de l'information vers le CU.

226 de 273
 Responsable du
programme

Comité d'évaluation

PM Gestion du budget

Figure 46 Diagramme des CU du ss-pm « 5- Gérer les demandes »

En regardant ce diagramme, nous nous posons la question : quelle serait l'attitude d'un
utilisateur face à cette image ? Ce diagramme des CU et ses symboles lui donnent-ils,
lors de la phase d'analyse, une description « lisible » et compréhensible de son métier,
meilleure que celle que nous avons décrite dans notre méthode à travers des modèles
ANSI ?.
Nous pensons que les modèles que nous avons développés avec les diagrammes ANSI
sont plus significatifs pour les usagers et bien plus utiles que seulement des
diagrammes de CU. Selon les approches orientées-objets actuelles, ces diagrammes (à

227 de 273
 la UML) seraient le point de départ d'une conception orientée objet du système à
réaliser. Selon notre point de vue, leur élaboration devient plus naturelle pour l'analyste,
et plus compréhensible, pour l'usager, après l'élaboration des diagrammes ANSI que
nous avons utilisés dans la méthode proposée. Dans ce point de vue, nous rejoignons,
celui de B. Moulin (Université Laval : cours Projet orienté-objet: conception et gestion)
qui insiste sur l'avantage de situer les méthodes 0 0 classiques au niveau conception et
non au niveau analyse.

Ainsi, suivant notre démarche, après avoir complété la phase d'analyse avec
l'élaboration des nouveaux modèles du PM objet, on peut démarrer la phase de
conception du système informatique en utilisant les techniques des méthodes de
conception orientées-objets. Ainsi, le concepteur peut partir des activités identifiées
comme automatisables dans les diagrammes du nouveau PM objet pour identifier les
use-cases de son systèmes et élaborer les diagrammes de use-cases. En procédant,
ainsi, L'arrimage entre le nouveau PM objet et le nouveau système informatisé sera
évident et cohérent. Les utilisateurs seront alors à l'aise pour le valider et suivre le travail
de conception des informaticiens.

5.8 Conclusion

Dans ce chapitre, nous avons appliqué la méthode, proposée, à un cas réel afin de
nous permettre de détecter les points forts, les points faibles ainsi que la perception des
acteurs qui ont participé à l'application de la méthode.
Au début de ce chapitre, nous avons présenté le contexte du cas étudié, sa description,
la mission et les objectifs de l'unité organisationnelle, propriétaire du PM objet en
question, ainsi que les difficultés que cette dernière rencontre dans la gestion actuelle
du PM objet.

Dans la phase d'initialisation de l'étude, en plus de la définition des ressources affectées

à l'étude et des plannings des échéances et des rencontres de travail, nous avons
cherché à clarifier davantage la demande du client et de ses objectifs afin d'en avoir une
compréhension plus étendue et une vision commune pour l'ensemble des intervenants.
Cet aspect est essentiel pour partir sur de bonnes bases et éviter des retours en arrière
souvent coûteux.
228 de 273
Lors de la phase de l'étude préliminaire, nous avons détaillé le mandat de la DAS au
sein du Ministère afin de nous permettre, par la suite, d'identifier les domaines qu'elle
gère, les processus métier de chaque domaine et la position du PM objet par rapport
aux autres domaines et aux autres PM qu'ils contiennent. Nous avons également fourni
une description détaillée du PM objet, des problèmes perçus (ou vécus) par les
personnes utilisant ce PM. Ensuite, nous avons procédé à l'identification des domaines
de l'unité organisationnelle et des PM les composant; puis à la définition des frontières
du PM objet qui nous a permis d'identifier ce qui fait partie de ce PM et ce qui ne l'est
pas (activités exclues).
À partir de ces éléments et des entrevues avec différents intervenants, nous avons pu
dresser la liste des acteurs externes, la liste des messages échangés et dessiner le
diagramme de contexte qui fournit une image, du PM objet, plus facile à appréhender et
à comprendre par le lecteur.

Dans la phase de diagnostic, nous avons, d'abord, analysé l'environnement du PM objet

en présentant les lois, les règles et les politiques auxquelles est soumise l'unité
organisationnelle; puis complété la liste la liste des messages échangés entre le PM et
ses acteurs et identifié les tendances technologiques du Ministère, notamment
l'obligation d'utiliser l'outil Oracle et les systèmes serveurs. Nous avons, également,
cherché à identifier les parties déjà automatisées du PM objet et les donnés confinées,
soit dans des BD, des fichiers ou tout autre support, afin de les prendre en considération
lors de la modélisation.
Ensuite, les travaux se sont focalisés sur la collecte de l'information sur le PM objet (en
le regardant de l'intérieur), notamment sur ses composantes (acteurs (internes),
messages échangés et activités composant le PM objet), sur ses performances (critères
d'efficacité et d'efficience), sur les problèmes et leurs causes probables. À partir de ce
niveau, les modèles du PM objet ont été élaborés sous forme graphique afin de mieux
en comprendre le fonctionnement et d'aboutir à une vision commune (pour l'ensemble
des intervenants) sur les enchaînements et les produits des activités du PM objet.
Toute l'information collectée lors de cette phase, notamment celle synthétisée dans les
modèles, celle décrite dans la fiche des problèmes et celle précisant les critères
d'efficacité et d'efficience, a été utilisée pour poser le diagnostic sur la situation actuelle,

229 de 273
en mettant, en regard de chaque problème identifié, les causes probables et leurs
impacts sur la gestion actuelle ou sur les acteurs qu'ils soient internes ou externes.

Lors de la phase d'analyse, nous avons proposé des solutions permettant d'éliminer les
problèmes énoncés ou du moins réduire leurs impacts. Ces solutions ont été présentées
à l'ensemble de l'équipe de travail et nous avons retenu celles acceptées, en commun
accord, et validées par la responsable du PM objet.
Les solutions retenues ont été utilisées comme base pour la conception des modèles du
nouveau PM objet, en identifiant les parties candidates à une automatisation de celles
qui ne le sont pas. Avant de procéder à l'élaboration de ces nouveaux modèles, nous
avons présenté les objectifs du nouveau PM objet, les objectifs du PM cible (partie à
automatiser) ainsi que les bénéfices escomptés par la transition du PM objet actuel vers
le nouveau PM objet.

Une fois les modèles du nouveau PM objet définis, nous avons soulevé la
problématique des méthodes orientées-objet par rapport à la phase d'analyse des
systèmes, en montrant, à travers l'exemple des diagrammes des cas d'utilisation, qu'il
est plus utile d'appliquer les méthodes 0 0 au niveau conception plutôt qu'au niveau
analyse.

Tout au long de ce chapitre, l'application de la méthode proposée, au cas choisi, a

permis, au demandeur et à ses collaborateurs, de mettre en exergue l'importance d'une
démarche par processus métier. Cela leur a permis, d'une part, d'avoir une vision
globale des différentes activités qu'ils mènent quotidiennement sans « penser » ou « se
soucier » des nombreuses interactions (explicites ou implicites) qui existent entre eux, et
d'autre part, de cerner davantage les différents acteurs qu'ils servent ou sont servis par,
de connaître les impacts des problèmes rencontrés actuellement et de découvrir
d'autres PM (notamment le PM GDUNO) qui peuvent leur fournir des données, fiables et
à jour, au lieu des listes qu'ils gèrent de façon quasi-manuelle avec tout ce que cela
implique : redondance, mise à jour aléatoire, perte de temps, fiabilité, etc.

Suite à l'application de la méthode proposée, nous pouvons alors entamer la conclusion

générale de ce mémoire et dans laquelle nous essayerons d'établir le bilan et les
apports de la méthode, ainsi que les limites et les perspectives. C'est l'objet du prochain
chapitre.

230 de 273
CHAPITRE 6 : CONCLUSION GÉNÉRALE

6.1 Introduction
Dans ce travail, nous nous sommes intéressés aux processus métier et à leur
modélisation dans le cadre de l'administration Québécoise. Le but de cette étude est de
présenter un échantillon des méthodes et des outils disponibles sur le marché et traitant
de la modélisation des processus métier, et de s'en inspirer afin de proposer les
principes d'une nouvelle méthode qui soit simple, facile à utiliser et surtout applicable
dans on intégralité. Cet objectif de simplicité, de facilité et d'intégralité émane
principalement du constat que les méthodes actuelles sont trop complexes pour
l'usager, soit par le langage utilisé, souvent sophistiqué ou trop technique, soit par leur
recherche d'universalité (être applicables à tous les cas et à toutes les organisations) en
vue de conquérir une plus large part du marché. Toutefois, cette recherche
d'universalité fait en sorte qu'aucune méthode n'est jamais appliquée dans sa totalité; ce
qui oblige les clients à effectuer de continuelles adaptations d'un projet à l'autre, à se
poser les mêmes questions à chaque fois (quoi prendre ? quoi laisser ? quoi modifier
dans la méthode utilisée ?) et, sans nul doute, à supporter les conséquences d'une telle
situation : perte de temps, coûts supplémentaires en formation et en réadaptations,
divergence des points de vue car chacun adapte la méthode à sa façon; ce qui donne
l'impression qu'il y a une multitude de méthodes au sein de la même organisation.

Pour mener ces travaux, ce mémoire a été décomposé selon 6 volets :

• Dans le chapitre 1 nous avons présenté le contexte de l'étude et ses objectifs ainsi
que la démarche à suivre pour réaliser les travaux.
• Dans le deuxième chapitre, nous avons évoqué la problématique de la modélisation
en commençant par une définition des notions de processus métier et de modèles et
une description des principaux rôles des modèles pour mieux comprendre les
mécanismes clés du métier et instaurer un langage commun aux divers acteurs afin
d'élaborer un système d'information adéquat, capable de supporter le métier, agir
comme base pour améliorer la structure actuelle et les opérations du métier et
montrer la structure d'un nouveau métier en montrant les nouveaux changements à
introduire au métier actuel. Nous avons, également abordé les différents niveaux de

231 de 273
 modélisation de l'activité de l'entreprise dans ses dimensions conceptuelle et
organisationnelle. Le but recherché par le dirigeant sera non seulement de concevoir
son système d'information mais d'une manière plus large, de modéliser le
fonctionnement de son entreprise dans sa dynamique et sa complexité, d'analyser
ses risques, de concevoir sa stratégie pour changer son organisation et améliorer sa
compétitivité.

• Dans le troisième chapitre, nous avons évoqué la problématique de la prolifération,

sur le marché, de méthodes, outils et langages de modélisation, presque tous
prétendant répondre à tous les besoins de modélisation, et de la difficulté de choisir
parmi cette panoplie. L'objectif de ce chapitre a été de présenter un ensemble de
méthodes et d'outils de transformation inter-modèles actuellement sur le marché,
d'essayer d'établir une comparaison entre les méthodes, d'une part, et entre les
outils d'autre part. Pour ces méthodes et outils de modélisation nous avons présenté
leurs caractéristiques fondamentales, leurs points forts et leurs points faibles. Il aurait
été idéal d'aboutir, à la suite de cette comparaison, à une méthode répondant à notre
problématique, c'est-à-dire une méthode de modélisation avantageuse à la fois en
termes de facilité d'utilisation, de rigueur dans la démarche et de complétude. Mais,
cela s'avère impossible. En effet, chaque méthode présente des avantages et des
inconvénients. Elles sont de plus orientées vers des buts différents en terme
d'utilisation et principalement orientées vers le processus de développement de
logiciel plutôt que vers la modélisation des métiers des organisations.
Selon le contexte initial de ce mémoire, nous devions nous limiter à déterminer
laquelle des méthodes étudiées s'adapte le mieux au contexte de l'administration
québécoise. Malheureusement (pour l'étudiant), heureusement pour la recherche,
aucune n'a fait le poids, par rapport aux critères établis (facilité, rigueur, complétude,
orientation processus métier), et il fallait proposer une nouvelle. C'est ce que nous
avons tenté dans le chapitre 4.

• Dans le quatrième chapitre, nous avons évoqué, au début, les motivations qui nous
ont guidé à proposer la méthode décrite dans ce mémoire, notamment l'absence sur
le marché d'une méthode applicable dans sa totalité, simple à utiliser, ne nécessitant
pas d'adaptation à chaque cas, n'exigeant pas d'expertise approfondie pour être
232 de 273
 maîtrisée et axée sur les processus métier. Ensuite, nous avons montré comment
utiliser l'étude préliminaire pour circonscrire le processus métier sur lequel porte la
demande en fonction des objectifs identifiés. Dans la phase de diagnostic nous
avons montré comment faire la synthèse de l'existant en analysant l'environnement
du PM objet afin d'être en mesure d'identifier les contraintes que cet environnement
pose, de même que les opportunités qu'il offre; ensuite nous avons défini les
modèles du PM objet, énuméré les problèmes, leurs causes et leurs impacts ainsi
que les objectifs que devrait atteindre le PM objet une fois transformé et avons
suggéré quelques éléments de solutions qui permettraient d'atteindre ces objectifs.
Lors de la phase d'analyse nous avons traduit le diagnostic, réalisé, sous forme
d'objectifs clairement formulés en proposant des solutions visant l'optimisation du
processus objet. La solution retenue par les décideurs est alors utilisée comme base
pour la conception des nouveaux modèles du nouveau PM en identifiant clairement
les parties candidates à une automatisation (PM cible) de celles qui ne le seront pas.

• Dans le cinquième chapitre, nous avons appliqué la méthode, proposée, à un cas

réel afin de nous permettre de détecter les points forts, les points faibles ainsi que la
perception des acteurs qui ont participé à l'application de la méthode. Le PM objet
choisi a été modélisé en entier et les solutions retenues ont été utilisées comme
base pour la conception des nouveaux modèles du nouveau PM objet, en identifiant
le parties candidates à une automatisation de celles qui ne le sont pas. Avant de
procéder à l'élaboration de ces nouveaux modèles, nous avons présenté les objectifs
du nouveau PM objet, les objectifs du PM cible (partie à automatisée) ainsi que les
bénéfices escomptés par la transition du PM objet actuel vers le nouveau PM objet.
Dans ce chapitre, nous avons suggéré de « placer » les méthodes 0 0 au niveau
analyse et non au niveau conception. Nous avons utilisé, les diagrammes d'utilisation
d'un ss-pm du nouveau PM objet, pour appuyer notre suggestion.

• Dans le présent chapitre (6ème), nous faisons un bref retour sur les méthodes de
modélisation analysées en synthétisant les résultats dans un tableau comparatif;
ensuite nous allons essayer d'établir le bilan et les apports de la méthode proposée
ainsi que ses limites et ses perspectives.

233 de 273
6.2 Tableau comparatif des méthodes
Dans le Tableau 62, nous présentons les méthodes suivantes :
• MERISE [[28], [29]] : représentative des méthodes systémiques (au sens de Le
Moigne [30]), et dont la finalité est l'analyse et la conception de systèmes d'information
(reposant sur une base de données).
• OMT (Object Modeling Technique) [31] : certainement une des plus représentatives
des méthodes d'analyse et de conception orientées objets utilisée dans les entreprises
avant l'apparition de UML (cf. ci-dessous). Bien entendu, d'autres méthodes bien
connues auraient pu également être considérées, telles les méthodes proposées par
Booch [33], Coad et Yourdon [34] ou Jacobson [35].
• UML (Unified Modeling Language) [32] : Langage de modélisation et de conception
unifiant (pour la représentation) les modèles présents dans les principales méthodes
orientées objets [[36], [37]]. Une comparaison sommaire avec OMT permettra de
constater si UML est mieux adapté à la modélisation d'organisations qu'OMT.
• SADT (Structured Analysis and Design Technique) [38] : inspirée des concepts
proposés par Ross [39] et représentative des méthodes dites cartésiennes ou
structurées, telle SA (Structured Analysis) [40], orientées vers les phases d'analyse et
de spécification.
• OSSAD (Office Support System Analysis and Design) [41] : méthode d'analyse et de
spécification de systèmes d'information centrée sur l'organisation du travail.
• UP (Processus Unifié) [46] est un processus de développement logiciel « itératif et
incrémental, centré sur l'architecture, conduit par les cas d'utilisation et piloté par les
risques ». Son principe méthodologique peut également s'appliquer à la modélisation
des processus métier.
• 2TUP (2 Tracks Unified Process) de Valtech [49] est un processus UP mais en forme
Y. L'axiome fondateur de 2TUP a été le constat que toute évolution imposée au
système d'information peut se décomposer et se traiter parallèlement, suivant un axe
fonctionnel et un axe technique. La fusion des deux axes conduit à l'obtention d'un
processus de développement en forme de Y.
• GPS (Gestion des ParcourS) : Élaborée en 2001 par la CSST (Commission de la
santé et de la sécurité du travail du Québec) la méthode GPS [50] a pour objectif
principal de fournir aux utilisateurs et aux développeurs un cadre de développement

234 de 273
unique pour tous les projets de la CSST et dans lequel les activités à réaliser
(appelées parcours) et les biens livrables sont clairement définis et limités en nombre.
DMR Macroscope (de DMR Conseil) [63] : Une suite intégrée de méthodes
d'entreprise et Tl, aide les entreprises à planifier, mettre en œuvre et gérer leurs
changements organisationnels par des initiatives clés comme la planification
stratégique, la transformation organisationnelle, l'architecture d'entreprise et
technologique, le développement, la mise en œuvre et la maintenance d'applications
et de systèmes, ainsi que par la gestion de portefeuille et de projets. DMR Macroscope
se divise en cinq domaines distincts, qui comportent chacun leurs propres méthodes
pour atteindre leurs objectifs. Ces domaines sont : Labo Architecture, Suite
Management, Centre Productivité, Station Résultats et Forum Stratégie.
Nous nous intéressons, ici, uniquement au domaine Centre Productivité (appelé aussi
DMR Productivité) car il est utilisé au Ministère de L'Éducation, du Loisir et du Sport.
DMR Productivité comprend des processus-types (appelés parcours) qui fournissent
une approche de parcours génériques pour le développement de systèmes
informatiques. Tous les parcours proposent des techniques de conception et de
modélisation orientées objet, en cohérence avec UML, et les techniques plus
traditionnelles de modélisation dites données-processus. Chaque parcours définit les
biens livrables à produire. Les principaux parcours sont :
• Parcours de développement générique : convient lorsque le système d'information
ne peut plus être simplement réparé ou amélioré, que l'utilisation de progiciels et
celle du développement accéléré comme base de solution ont été écartées.
L'exhaustivité et la profondeur de ce parcours sont appropriées pour faire face aux
risques inhérents aux grands projets, mais s'adaptent très bien aux plus petits
projets évoluant dans un environnement complexe.
• Parcours de développement accéléré : optimise l'utilisation d'équipes compétentes
et bien outillées dans le cadre de projets à échéances serrées pour lesquels la
rapidité de la livraison est un facteur essentiel. Certaines conditions doivent
toutefois être présentes par exemple, équipe de réalisation spécialisée, type
d'application bien connu, processus d'entreprise bien défini, technologies
maîtrisées, etc.

235 de 273
 • Parcours de mise en oeuvre d'une solution progicielle : s'applique aux situations où
des solutions progicielles et les services constituent l'essentiel de la mise en
oeuvre. Ce parcours s'applique aux projets de différentes envergures. Il couvre la
sélection, l'adaptation et la mise en oeuvre de la solution progicielle. Il comporte
aussi la conversion des données, la création d'interfaces avec les systèmes
existants, ainsi que la modification du progiciel lorsque nécessaire.
• D'autres parcours existent mais ne sont pas en lien avec l'objet de ce mémoire tels
que Parcours de gestion de demandes de maintenance (qui analyse les demandes
de changement, établit les priorités et les regroupe en unités de travail.), Parcours
d'amélioration technique (qui applique les changements relatifs à l'infrastructure
technologique d'une application), etc.
Comme la méthode GPS, DMR Productivité utilise la notion de parcours et offre
quasiment les mêmes façons de faire que GPS (nous ne savons pas laquelle s'est
inspirée de l'autre et nous préférons la notion de coïncidence). La différence principale
réside dans l'appellation des parcours et de la terminologie utilisée. En raison de cette
similitude, nous avons évité de présenter les deux méthodes dans le chapitre 3 en se
limitant à GPS. D'ailleurs, nous constatons, dans le Tableau 62 que ces méthodes
répondent quasiment aux mêmes critères d'évaluation.
Et pour faciliter la comparaison des différentes méthodes, nous les avons regroupées
dans le Tableau 62 afin de permettre au lecteur de les comparer selon la dimension qu'il
juge la plus pertinente pour son domaine d'intérêt, (cf. chapitre 3, section 3.3, pour
l'explication du cadre de comparaison et des dimensions). Nous avons inséré, dans ce
tableau, une colonne pour notre méthode afin que sa comparaison avec les autres
méthode soit établie selon le même cadre de comparaison.

236 de 273
 • • • • • • • • • ••

JProdu-
.
• . : .

c A ryr 2TUP GPS Notre

Dimension Critères UP
méthode
..... ctivité
Cycle de Cascade X X X
développe- Spirale X
ment Y X X
Incrémental X X X X X
Analyse X X X X X X X X X
Modélisation X X X X X X X X X
Phases
concernées Conception X X X X X X X X
Validation X X X
X
technique
Descendante X X X X X X X
Approche Ascendante
Evolutive X X
Pas
Degré Peu X
d'implication Moyen X X
de l'utilisateur Beaucoup X X X X X
Essentiel X X X X
Moment Début X X X X X X X X X
d'implication Milieu X X X X X X
de l'utilisateur Fin X X
Position de Interprétée X X X X X X
l'analyse Directe X X X X
Principe de Données 1 1 1,3 1 3 1.3 1,3 2,4 2,4 5
construction Activités 1 3 2,4 1 1 2,4 2,4 1,3 1,3 1,3
( ordre Traitements 2 6 2 6 6 6 6 4
d'apparition
des Dynamique 2 5 5 5 5 5 2
formalismes)
Niveaux
X X X X X X X X
d'abstraction
Généralisation
X X X X X X X X X
Principe / Spécification
d'assemblage Type/
X X X X X X X
Occurrence
Stratégique /
X
Tactique
DC
M.C.D., DC, Fiches DC, DC,
Data- Ou
Données M.O.D., M.O DO, OSSA DO, DO, DC
gramme Entités-
M.L.D. Dcol D Dcol Dcol
Relations
Diag. A1,
Activités M.C.C. D.F.D
eu, Acti-
A2, D1,
eu, eu, eu eu ANSI
Dseq. gramme Dseq. Dseq.
D2
Formalisme
M.C.T.,
Diag. D3,
Traitements M.O.T., DA DA DA DA DA ANSI
D4, D5
M.P.T.
Diag.
Evts, DC,
Dynamique D.E. D.E. DC DC ANSI
D.E. D.E.
évolué
Outils asso- Oui X X X X X X X
ciés Non X X X

237 de 273
 DMR
Dimension Critères MERISE OMT UML OSSAD . yp G PS Produ»
méthode
Oui X X
Standard
Non X X X X X X X X
Faible X X
Flexibilité Moyenne X X X X X X X X
Forte
Coût
d'acquisition
Complexité
Faible X X X
Moyenne X X X X X
d'utilisation
Forte X X
Structuré X X X X X X X X X X
Semi-
X X X X X X
structure
Nature de
Non structuré X X X
l'environne-
Stable X X X X X X X X i X X
ment
Instable X X X X X X X
Certain X X X X X X X X X X
Incertain

Tableau 62 Comparaison des méthodes

Légende
A1 : relations (de données) entre fonctions et sous-fonctions.
A2 : Matrice Activité / Rôle.
CU : Cas d'Utilisation
D 1 : Relations (de données) entre Rôles.
D 2 : Relations (de données) entre rôles et tâches
D 3 : Diagramme d'une tâche (liée à 1 rôle).
D 4 : Diagramme d'une procédure incluant plusieurs rôles.
D 5 : Détail d'une opération ou d'une tâche (basé sur les actigrammes).
D.E. évolué : Diagramme d'état évolué
D.F.D. :Diagramme de Flux de Données
DA : Diagramme d'Activités
DC : Diagramme de Classe
Dcol : Diagramme de Collaboration
DE : Diagramme d'État.
Diag. Evs : Diagramme d'événements
DO : Diagramme d'Objet
DSeq : Diagramme de Séquence
Fiches : Les fiches permettent de décrire les ressources, les rôles, les acteurs, les unités, les tâches,
les opérations, les procédures et les outils.
M.C.C. : Modèle Conceptuel des Communications
M.CD. : Modèle Conceptuel des Données
M.L.D. : Modèle Logique des Données
M.O. : Modèle Objet
M.O.D. : Modèle Organisationnel des Données
M.O.T. : Modèle Organisationnel des Traitements
M.P.T. : Modèle Physique des Traitements.

238 de 273
Dans le tableau qui suit, nous essayons (même s'il est difficile de le faire) de situer notre
méthode par rapport à l'ensemble des méthodes étudiées selon d'autres dimensions telles
que l'approche utilisée, la façon de représenter les processus, l'implication de l'usager, le
passage de la modélisation à la conception, le volume des biens livrables, l'expertise exigée
pour mener les étapes de la méthode, etc. Nous avisons le lecteur que ceci est un simple
essai de comparaison car, pour un meilleur résultat, il aurait fallu tester l'ensemble des
méthodes sur des cas variés; ce qui est, malheureusement, hors de notre portée.

• " • ' / • • •

Asoect Notre méthode Les sutres méthodes étudiées

Approche
• Processus métier X
• Système d'information X
• AGL (Atelier de génie
X
logiciel)
Diagrammes et symboles nouveaux
Diagrammes ANSI connus pour l'usager et plus proches de la
Représentation des
par les usagers depuis conception que de l'analyse
processus
longtemps (composant, objet, classe,
package, etc.)
Volume des livrables Quelques fiches Nombreux documents
Combinent le vocabulaire de
l'usager avec un vocabulaire
informatique et utilisent beaucoup
Simple (vocabulaire du
Vocabulaire utilisé d'acronymes qui déroutent l'usager
métier de l'usager)
(MOT, diagramme de packages,
diagrammes d'activités, composant,
etc.)
Implication de l'usager Du début à la fin Souvent limitée aux phases initiales
Une journée (d'après notre
Formation nécessaire pour
expérience pour mener Plusieurs sessions.
apprendre la méthode
l'étude du cas)
Obligatoire car selon le cas,
Réadaptation de la
certaines étapes s'appliquent ou ne
méthode à chaque type de
Aucune s'appliquent pas ou doivent être
PM ou à chaque
modifiées. De même pour les
organisation
livrables.
Passage de la modélisation Passage naturel car la Partent, généralement, du projet à
des PM à la conception du modélisation montre les automatiser pour lequel elles font
système informatique parties à automatiser. l'analyse et la conception.

239 de 273

Facilité du choix, par
l'usager, des solutions
proposées
Outils de modélisation
associés
Très facile car les éléments
d'aide à la décision sont La documentation fait référence
présentés sur la même fiche, aux problèmes et aux solutions
jouant le rôle d'un tableau de mais de façon éparpillée dans la
bord pour l'usager (cf. documentation. L'utilisateur ne
Tableau 38 : : problèmes, dispose pas d'une fiche jouant le
impacts et solutions rôle d'un tableau de bord
proposées)
La majorité ont des outils associés
Ceux qui permettent de
ou peuvent l'être (OSSAD, UP,
tracer des diagrammes ANSI
2TUP, GPS, DMR Productivité)

Tableau 63 Comparaison de la méthode proposée avec les autres méthodes étudiées

6.3 Bilan et apports de la méthode

Durant l'application de la méthode, ce qui nous a frappé le plus, lors des discussions
avec les intervenants de l'unité organisationnelle, c'est une forme de renonciation
devant les obstacles rencontrés lors de l'application de l'une ou l'autre des méthodes
actuellement disponibles sur le marché. Cette forme de renonciation est due,
principalement, à la complexité de ces méthodes, notamment par le nombre trop grand
de concepts à assimiler, le nombre de livrables à valider (et à comprendre avant tout) et
le nombre d'étapes variant d'un projet à un autre.
Cette forme de renonciation est également due au fait que ces méthodes sont longues à
mettre en place, souvent coûteuses, utilisent un langage pas toujours à la portée des
clients, surtout les non informaticiens, et dont la documentation produite, une fois
validée, est mise à une quasi-oubliette à cause de sa lourdeur et de son volume. Tous
ces facteurs n'aident pas à résoudre la résistance au changement des individus et des
unités administratives de l'organisation.

La méthode, que nous avons proposée, a été présentée à cinq intervenants de profils
différents (responsable du programme, professionnel qui gère les demandes,
comptable, informaticien et secrétaire). Elle a été accueillie, au début, avec la même
méfiance qu'à l'égard des autres méthodes. Pour faire dissiper cette méfiance, proche
du rejet, nous avons présenté les principes de base de notre méthode ainsi que l'objectif
de notre mémoire/celui de simplifier, faciliter et parler le langage du client.

240 de 273
Dès le début de l'application de la méthode, la méfiance a rapidement cédé à la
confiance. Ce revirement de situation a continué tout long de l'étude de cas. Cela n'est
pas du à une méthode meilleure que les autres (loin de là) mais plutôt à la simplicité de
la méthode proposée, au langage usuel utilisé et à une documentation limitée à une
série de fiches et de diagrammes ANSI synthétisant ce que désire savoir le client et ce
qui peut le guider dans ses choix et ses décisions.

Parmi la documentation produite, Le diagramme de contexte a été, sans nul doute, le

plus apprécié car il a permis de donner, en une demi-page, une vision globale sur le PM
objet avec ses fournisseurs, ses clients, ses entrées (inputs) et ses sorties (outputs).
Quant aux modèles utilisés pour décrire l'ancien PM objet, ils ont permis aux
intervenants de l'unité organisationnelle d'avoir une vision plus réaliste des nombreuses
tâches qu'ils accomplissent et des échanges, entre eux, effectués parfois de manière
implicite. Cette vision réaliste a beaucoup contribué à la conception des nouveaux
modèles du nouveau PM objet, notamment par la découverte de relations possibles
avec d'autres PM de l'organisation, en particulier le PM GDUNO qui emmagasine toute
l'information dont a besoin le PM objet pour communiquer avec l'ensemble de ses
acteurs externes. Cette découverte a permis un gain considérable en temps, en coûts et
en fiabilité des données car toutes ces informations sont gérées manuellement dans
l'ancien PM objet. Le nouveau PM objet, en puisant ses données dans le PM GDUNO,
s'assure d'une donnée fiable et se décharge d'une tache redondante, fastidieuse et
coûteuse.
Cela a été clairement démontré dans les nouveaux modèles du nouveau PM objet, dans
lesquels les parties candidates à une automatisation ont été identifiées par rapport à
celles qui ne le sont pas. Cette identification a été largement facilitée par la fiche (cf.
Tableau 61) qui synthétise les problèmes rencontrés dans l'ancien PM objet, leurs
causes, leurs impacts, les solutions proposées par l'analyste et celles retenues par les
clients. Cette fiche a été très bien appréciée par les différents intervenants car elle a
permis, d'une part, d'avoir une vision globale de l'ensemble des problèmes dont chacun
ne voyait qu'une partie (celle qu'il vit ou ressent) et d'autre part, de faciliter le choix de la
solution appropriée en regard de l'impact à éliminer ou à réduire.

241 de 273
Au-delà des apports, énumérés ci-dessus, de la démarche proposée, nous avons tiré
deux sonnettes d'alarme que nous jugeons essentielles. La première, sur le dérapage
«méthodologique », au sein de l'administration, qui engloutit des sommes faramineuses,
non pas à cause de la compétence (celle-ci est excellente), mais plutôt à cause de la
complexité des méthodes utilisées. Il est peut être temps de revoir les façons de faire
« méthodologiques » afin d'épargner du temps et de l'argent.
La deuxième sonnette d'alarme est celle relative aux méthodes OO et dans laquelle
nous avons suggéré de dissocier l'analyse de la conception. Dans notre approche, nous
avons mené l'analyse du PM objet selon une démarche à la portée du premier concerné
(l'utilisateur) en utilisant un discours composé de son propre langage métier (fiche des
problèmes rencontrés, fiche des impacts et solutions proposées, etc.) ainsi que de
diagrammes ANSI, mis aux oubliettes dans les nouvelles méthodes alors qu'ils ont été
largement acceptés par les usagers pendant de nombreuses années qui ont précédé
l'arrivée des méthodes orientées-objets sur le marché. Nous avons montré, à travers
l'exemple des cas d'utilisation (cf. 5.7) l'avantage de situer les méthodes OO classiques
au niveau conception et non au niveau analyse.
Nous désirons également profiter de ce mémoire, pour lancer un appel à une
collaboration plus étroite entre l'administration et le monde de la recherche universitaire
dans le domaine de l'informatique. En tant qu'étudiant (pour ne parler que de moi-
même), je me suis toujours posé la question suivante : Pourquoi une bonne partie des
savoirs théoriques et pratiques appris à l'école ne sont pas utilisés dans mon milieu de
travail ? En l'absence d'une réponse plausible, nous pensons qu'une coopération étroite
entre ces deux milieux (enseignants, administrations) permettrait d'éviter le dérapage
méthodologique, que nous avons évoqué, ou du moins d'analyser profondément les
raisons qui ont conduit à une telle situation au sein de l'administration.

Toutefois, la méthode proposée ne prétend pas être complète. Certaines améliorations

doivent être apportées. Dans la section qui suit, nous allons essayer de décrire ses
limites et ses perspectives.

242 de 273
6.4 Limites et perspectives

À notre avis, pour juger de l'efficacité d'une méthode, il faudrait l'appliquer à plusieurs
cas différents. La confrontation avec de nombreux domaines et de nombreux processus
métier de natures différentes semble être une phase clé pour tester le dispositif
méthodologique que nous avons proposé. Nous n'avons pas pu le faire faute de temps
et de moyens.
Outre cette limite, il reste à mûrir et à valider les modèles, utilisés dans notre démarche,
et ce dans le cadre d'une modélisation globale du Ministère, en grandeur nature, pour
détecter d'éventuels liens avec d'autres PM ou d'éventuelles redondances.

D'un autre coté, la méthode proposée ne prévoit pas de mécanismes pour réduire la
difficulté de consultation et de validation auprès des experts métier : Les rendez-vous
sont difficiles à organiser, les personnes sont parfois réticentes à donner un avis car,
soit que leur mandat n'est pas clair au sein de l'organisation, soit qu'elles ne sont pas
autorisées à le donner, etc. Ces aspects allongent les délais, biaisent l'expression des
besoins et peuvent porter atteinte à la qualité des résultats de la méthode proposée.

À terme, notre travail débouche sur quelques perspectives de recherche que nous
avons jugées particulièrement intéressantes et que nous proposons à l'exploration :
• Construction du système documentaire : Outiller la méthode avec un mécanisme de
gestion, de la documentation produite, facilitant la mise à jour, la consultation et
gérant les liens entre les différents livrables;
• Constitution d'un dictionnaire de données générique : Ce dictionnaire permettait de
décrire de manière uniforme toute l'information utilisée dans les modèles et
faciliterait sa compréhension;
• Introduction de l'axe temporel : Les fonctions mises en évidence dans les modèles
sont décrites par un enchaînement d'opérations. La prise en compte de l'axe
temporel permettrait de décrire quand les opérations sont effectuées. Une recherche
dans ce sens pourrait s'inspirer des diagrammes d'état (state Charts) d'UML utilisés
en atelier du logiciel;

243 de 273
Vérification de la cohérence inter modèles. En effet, celle-ci a été faite manuellement
par l'équipe de travail. Ceci provient d'un choix délibéré afin d'impliquer totalement
l'utilisateur dans la modélisation et d'éviter une modélisation assistée par ordinateur
qui banaliserait la création de modèles. Toutefois, une vérification automatique de la
cohérence inter-modèles serait bien perçue de la part des modélisateurs et
permettrait de faciliter la gestion de la cohérence.
Évaluation des coûts : Doter la méthode d'un outil d'évaluation des coûts de la
transition du PM objet actuel vers le nouveau PM objet. Cet aspect, quoique pas
toujours facile à cerner, est assez intéressant dans la mesure où il offrirait aux
décideurs une vision plus éclairée sur l'avenue à emprunter.

244 de 273
BIBLIOGRAPHIE

[I] J.L. Le Moigne, "La modélisation des systèmes complexes." Ed. Dunod 178p, Paris
1990.
[2] Neubert, G., "Contribution à la spécification d'un pilotage proactif et réactif pour la gestion
des aléas." Thèse, Institut National des Sciences Appliquées de Lyon 1997.
[3] Object Management Group. Meta Object Facility (MOF) Spécification, 2000.
[4] Booch, G., J. Rumbaugh, and I. Jacobson. Unified Modeling Language, Version 1.1.
Rational Software Corporation, 1997.
[5] Bézivin, J., Who is afraid of ontologies ? In OOPSLA'98 Workshops, Vancouver, Canada,
October 1998. available at http ://www.metamodel.com/oopsla98-cdif-workshop/bezivin1/.
[6] Bézivin, J., Y. Lennon, and C. Nguyen Huu Nhon. From cobol to omt : A reengineering
workbench based on semantic networks. In Proceedings of Tools USA'95, pages
137_152, Santa Barbara, CA, USA, August 1995. Prentice Hall.
[7] CDIF Technical Committee. CDIF -Integrated Meta-model / Foundation Subject Area -
EIA/IS-111,1994.
[8] NCITS.T2 Committee. Conceptual Graph Standard - draft proposed American National
Standard - NCITS.T2/98-003, August 1999.
[9] Kettani, N., Mignet, D. Paré, P., Rosenthal-Sabroux, C, De Merise à UML, Ed. Eyrolles,
Paris, 1998.
[10] Eriksson, Hans-Erik., Penker, Magnus., Business Modeling with UML: business patterns
at work, John Wiley & Sons, 458 pages, 2000, ISBN: 0471295515.
II1] Le journal du net, Externalisation et Infogérance, Juin 2005, disponible sur
http://encyclopedie.journaldunet.com/php/commun/definition. php?id=439&idctnr=21&id_c
at=2&mode=1
[12] 2CW, L'extemalisation Stratégique, disponible sur http://www.2cw.com.tn.
[13] OMG, " UML Profile for CORBA Spécification " OMG document ptc/01-01-06, septembre
2000, http://cgi.omg.org/cgi-bin/doc7ptc/2001-01-06
[14] Bézivin, J., Workshop in Software Model Engineering, Tuesday October 1st 2002,
Dresden, Germany, disponible sur http://www.metamodel.com/wisme-2002/
[15] Université de Sherbrooks, Métamodélisation, disponible sur
http://www.dmi.usherb.ca/~sgiroux/Clublnfo/Calendrier_-Juin_2002/Seminaire_-
_12Juin_2002/2002-06-12_Perrot_Metaformalismes.ppt
[16] W3C, XML, disponible sur http://www.w3c.org/W3C.
[17] Laboratiore des sciences de l'information et des systèmes, Méthode SADT, disponible
sur http://www.lsis.org/dea/M6optionD/Exp-GL41-SADT.pdf.
[18] Encyclopédie informatique Comment Ça Marche , MERISE - Initiation à la conception de
systèmes d'information, disponible sur
http://www.commentcamarche.net/merise/concintro.php3.
[19] MetaCase, OMT, disponible sur http://www.metacase.com/french/methods/OMT.html.

245 de 273
[20] CORBA, What is CORBA?, disponible sur http://www.corba.org/
[21] Hidding, G.J., Methodology information : who uses it and why not?, Proc. WITS-94,
Vancouver, Canada, 1994.
[22] Bézivin, J., Object-Oriented Information System Analysis: Comparative Analysis of six
Object-Oriented Analysis Methods. IFIP Transactions: Methods and Associated Tools for
the Information System Life cycle, A. A. Verrijn-Stuart & T. W. Olle (Eds) North-Holland,
1994.
[23] C. Souveyet, R. Deneckere, C. Rolland, State of art : a comparaison of six oriented
analysis methods. TOOBIS project, deliverable T23D1.2, part 1, 1997.
[24] Song, S., Osterweil, L.J., Towards objective, systematic and design-method comparison.
IEEE Software, Vol. 34, No.5, May, pp. 43-53, 1992.
[25] Hong, S., G. Goor, V., S. Brinkkemper; A Formai Approach to the Comparison of Object-
Oriented Analysis and Design Méthodologies. Proceedings of the 26th Hawaii
International Conférence on Systems Science, J. Nunamaker, R. Sprague (Eds.), Vol. 4,
IEEE Computer Society Press, Los Alamitos, 1993.
[26] Rossi, M., S. Brinkkemper, Metrics in Method Engineering. Proceedings of the 7th
International Conférence on Advanced Information Systems Engineering CAISE'95,
Jyvaskyla, Finland, June 1995.
[27] Boehm, B.W., A spiral model of Software Development and enhancement, Volume 21,
Issue 5, Computer May 1988 Page(s):61 - 72.
[28]Tardieu, H., Rochfeld, O., Colleti, R., Panet, G., Vahee, G., La méthode Merise.démarche
et pratiques (tome 2). Editions d'Organisation : Paris, 1985.
[29] Tardieu, H., Rochfeld, O., Colleti, R., La méthode Merise, principes et outils (tome 1),
2ème édition. Paris : Editions d'Organisation,1991.
[30] Le Moigne, J.L., La théorie du système général - théorie de la modélisation. Vendôme :
Presses Universitaires de France, 1977.
[31] Rumbaugh J., Blaha M., Premerlani W., Eddy F., Lorensen W., Objectoriented modeling
and design. Prentice Hall, 1991.
[32] Rumbaugh, J., Jacobson, I., Booch, G., Unified Modeling Référence Manual.Addison
Wesley, 1998.
[33] Booch, G., Conception orientée objets et applications. 2ème édition, USA : Addison-
Wesley, 1994.
[34] Coad P., Yourdon E., Object-oriented design. Prentice Hall, 1991, ISBN 0-13-630054-5.
[35] Jacobson, I., Christenson, M., Jonsson, P., Overgaard, G., Le génie logiciel orienté objet,
une approche fondée sur les cas d'utilisation. USA : Addison-Wesley.ACM Press Books,
1993.
[36] Perrin, P., La guerre des standards des méthodes orientées objet n'aura pas lieu.
Ingénierie des Systèmes d'Information, 5, 5,1997, pp. 533-552.
[37] Muller, P.A., Modélisation objet avec UML. Paris : Eyrolles, 1997.
[38] I.G.L. Technology, SADT, un langage pour communiquer. Paris : Eyrolles, 1989.

246 de 273
[39] Ross, D.T., Structurée! analysis (SA) : a language for communicating ideas. IEEE
Transactions on Software Engineering, SE-3,1, Janvier 1997.
[40] DeMarco, T., Structurée! analysis and System spécification. USA : Yourdon Press, 1979.
[41] Dumas P., Charbonnel G., La méthode OSSAD, pour maîtriser les technologies de
l'information. Tome 1 : principes. Paris : Les éditions d'organisation, 1990.
[42] Barthet, M.F., Logiciels Interactifs et ergonomie. Modèle et méthodes de conception.
Paris : Dunod Informatique, 1988.
[43] Barthet, M.F., The DIANE Method and its connection with MERISE Method. Proceedings
IEA World Conférence "Ergonomie design, interfaces, products, Information", Rio de
Janeiro, Brazil, pp. 106-110, 16-20 October 1995.
[44]Tarby, J.C., Gestion automatique du dialogue homme-machine à partir des spécifications
conceptuelles. Thèse de doctorat, Université de Toulouse, septembre 1993.
[45] Morejon, J., MERISE, vers une modélisation orientée objet. Paris : Les Éditions
d'Organisation, 1994.
[46] Jacobson, I., Booch.G., Rumbaugh, J., The Unified Software Development Process,
Addison Wesley, 1999.
[47] UN/CEFACT, UMM Foundation - Project Information, disponible sur
http://www.untmg.org/
[48] Progest, La méthode RUP, disponible sur http://thieum22.free.fr/Quest_RUP.htm
[49] Roques, P., Vallée, F., UML en action - 2e édition : De l'analyse des besoins à la
conception en Java, Édition Eyrolles 11/2002, ISBN: 2-212-11213-0
[50] Méthode Gestion des Parcours (GPS) développée par Commission de la santé et de la
sécurité du travail du Québec (CSST) en 2001
[51] Internet Business Services, Benchmarks 2004-2005, disponible sur
http://www.ibsbusiness.com/en/default.asp.
[52] Rational Software inc, UML Documentation, disponible sur
http://www.rational.com/media/worldwide/france/uml_exec_fr.pdf
[53] Oryx-si, Outils de modélisation, disponible sur http://www.oryx-
si.com/telechargement/Choix_outils_modelisation.pdf
[54] Vernadat, F. B., Techniques de Modélisation en Entreprise. Applications aux processus
opérationnels, Economica, 1999,129 pages.
[55] Morley, C , Organizational change and process modeling, Article présenté au 5e colloque
de l'AIM (Association Information et Management) 8,9,10 novembre 2000 Montpellier,
France.
[56] Morley, C , J. Hughes, B. Leblanc, UML pour l'analyse d'un système d'information - Le
cahier des charges du maître d'ouvrage, Édition Dunod (26 juin 2003), ISBN :
2100079778.
[57] Laboratoire d'Informatique de Paris VI, Modélisation conceptuelle : Techniques de Méta-
Modélisation, disponible sur http://www-poleia.lip6.fr/~revault/papers/cari94-SR.pdf

247 de 273
[58] Moulin, B., Méthode E.P.A.S pour la modélisation et la conception de systèmes,
Université Laval, novembre 1988
[59] Harrington, H.J., Business process improvement, McGraw-Hill; 1 édition (April 1,1991),
274 pages, ISBN: 0070267685.
[60] R.C. CAMP, Benchmarking: The Search for Industry Best Practices That Lead to
Superior Performance, ASQC Quality Press, Milwaukee, Wis., 1989
[61] Benaissa M., Une démarche de conception, réalisation et évaluation d'IHM : application
au projet ferroviaire ASTREE. Thèse de doctorat. Université de Valenciennes et du
Hainaut-Cambrésis, Décembre 1993.
[62] Abed, M., Angue J.C., A new method for conception, réalisation and évaluation of man-
machine interfaces. Proceedings IEEE Systems, Man and Cybernetics conférence, (2-5
Octobre 1994 ; San Antonio, USA).
[63] DMR Cosneil, Méthodes et meilleures pratiques, disponible sur
http://www.metalink.com/fr/accueil/
[64] UN/CEFACT, UMM Foundation and Base Module, disponible sur
http://webster.disa.org/cefact-groups/tmg/
[65] Standishgroup, The Chaos Report, disponible sur
http://www.standishgroup.com/sample_research/chaos_1994_1 .php
[66] Highsmith, J.A. , Adaptive Software Development: A Collaborative Approach to Managing
Complex Systems (Paperback) 2004, ISBN 0-9326-33-40-4
[67] Harrington, J.H., La réingénierie des processus administratifs : le pouvoir de réinventer
son organisation. Montréal, 1994 (Collection Les Affaires). ISBN : 2-921030-62-4.
[68] http://www.granddictionnaire.com.
[69] American Productivity & Quality Center, Benchmarking and Best Practices, disponible
sur http://www.apqc.org.
[70] Rivard, S. Talbot, J.; Le développement de systèmes d'Information - Un méthode
intégrée, Presses de l'Université du Québec et des HEC, 2003, ISBN: 2-7605-1137-5

248 de 273
ANNEXES

249 de 273
 ANNEXE 01

Meta Object Facility (MOF)

et
Model Driven Architecture (MDA)

250 de 273
 TABLE DES MATIÈRES

1. MÉTA-MÉTA MODÈLE MOF 252

2. MDA : MODEL DRIVEN ARCHITECTURE 254
3. LE PIM - PLATFORME INDEPENDANT MODEL 256
4. PSM - PLATFORM SPECIFIC MODEL 258
5. DU PIM VERS LE PSM 260
6. ARCHITECTURE STRATIFIEE 262
7. LES DÉFIS DE L'OMG 264
8. RÉFÉRENCES 267

251 de 273
1. Méta-méta Modèle MOF

Le MOF (Meta Object Facility) a été adopté en 1997 par l'OMG. Il spécifie d'une part,
un langage pour la définition de méta-modèles, ce qui fait de lui un méta-méta modèle,
et d'autre part, une architecture de modélisation. Son objectif est de faciliter la gestion
des méta-données. Par exemple, UML est un méta-modèle dédié à la description des
artefacts logiciels à objets. Un méta-modèle contient un ensemble de concepts, de
relations entre ces concepts, et de contraintes.
Ainsi UML introduit entre autres les concepts de classes, d'attributs, d'associations et
de méthodes. Ces méta-modèles vont permettre de définir des modèles, servant eux
mêmes à décrire des instances. Le méta-modèle est du niveau du domaine, le modèle
de celui de l'application, et l'instance de celui du phénomène particulier et observable.

Notons d'ailleurs qu'à l'origine, UML est réflexif, c'est à dire qu'UML a été décrit en
UML. C'est cette partie réflexive qui a été légèrement remaniée et a donnée naissance
au MOF (Le Core [8] Package du méta-modèle UML est quasiment identique au
MOF). L'intérêt majeur de cette réflexivité est que des outils initialement conçus pour
manipuler des modèles pourraient être adaptés à moindre coût pour manipuler d'une
manière identique des méta-modèles. A titre d'exemple, le langage OCL (Object
Constraint Language), langage de contraintes qui permet de définir des assertions sur
des modèles UML est réutilisé au niveau du MOF. En pratique, dans un AGL (Atelier
de Génie de Logiciel), UML peut être utilisé pour manipuler des méta-modèles basés
sur le MOF.

Le MOF se retrouve au sommet d'une architecture à quatre couches. Cette

architecture, autour de laquelle s'est aujourd'hui formée un consensus, est composée
des niveaux suivants :

- M3, constitué du seul et unique MOF,

- M2, constitué par les méta-modèles,
- M1, constitué par les modèles,
- MO, constitué par les instances.

252 de 273
Le MOF définit un mécanisme d'interopérabilité entre méta-modèles. Comme ils sont
tous définis dans un même formalisme il est possible de les comparer et de les relier.
Ainsi, chaque domaine pourra être doté du méta-modèle qui lui est le plus adapté, ce
méta-modèle pouvant se baser sur des méta-modèles déjà existants et s'interfacer
avec des méta-modèles couvrant des domaines différents. Par exemple un méta-
modèle de processus peut être connecté à un méta-modèle de produit ou de structure
organisationnelle de l'entreprise. L'OMG avait déjà spécifié CORBA, un bus
d'interopérabilité entre des composants logiciels hétérogènes. Le MOF peut également
être vu comme un bus, mais un bus de d'interopérabilité entre des méta-modèles
hétérogènes.

Le MOF constitue donc la fondation de l'architecture de modélisation de l'OMG. Sur

cette base ont été développés des méta-modèles comme UML (notons que
chronologiquement UML précède le MOF) et un certain nombre de mécanismes. Parmi
ces mécanismes on peut citer XMI (OMG, 2000) (XML Metadata Interchange) qui
fournit un ensemble de règles permettant de générer directement le format XML
correspondant à un méta-modèle basé sur le MOF.

Ces technologies constituent le cœur du MDA (Model Driven Architecture). Cette

nouvelle proposition de l'OMG entend instaurer la primauté des modèles dans le
système d'information. Devant l'évolution permanente des technologies logicielles, le
MDA propose de séparer les aspects purement métier des considérations propres à la
plate-forme d'exécution. L'objectif est donc de préserver les informations stratégiques
de l'entreprise des changements technologiques. De plus les modèles vont constituer
un point de départ à la réalisation des composants logiciels. Alors qu'ils ne servaient
que de guide au développement de ces derniers, les techniques de transformation de
modèles et de génération de code font évoluer la situation. Le composant logiciel n'est
plus qu'un sous-produit du modèle puisqu'il est généré (au moins partiellement) à partir
des informations contenues dans le modèle.

Un certain nombre d'outils existent actuellement qui permettent d'implémenter des

méta-modèles basés sur MOF. A titre d'exemples, on peut citer :

253 de 273
 • DMOF : Outil développé par DTSC (Ditributed System Technology Centre) en
Australie pour la définition et la gestion des méta-modèles basés sur MOF [2].
• Universalis : Un référentiel de modèles développé par France Telecom R&D et
destiné à abriter tout modèle dont le méta-modèle est basé sur MOF [3].
• M3J : Outil graphique développé en partenariat entre LIP6 et EDF R&D, pour la
définition graphique de méta-modèles et de la génération des interfaces IDL et de
la DTD XMI [4]
• XMI tool kit d'IBM : Pour la manipulation des méta-modèles basés sur MOF. Il
fournit un ensemble de règles permettant de générer directement le format XML
correspondant à un méta-modèle basé sur le MOF [5].

2. MDA : Mode! Driven Architecture

L'OMG (Object Management Group) a rendu publique, en novembre 2000 à Orlando,

sa nouvelle orientation dans un document intitulé MDA (Model Driven Architecture) [6].
Il s'agit du constat, plus de 10 ans après la création de l'OMG, que la recherche de
l'interopérabilité dans les systèmes d'information ne peut être atteinte uniquement
grâce à la standardisation des infrastructures de middleware, mais par une approche
beaucoup plus globale où la notion de modèle devient essentielle et centrale.

Le principe de base du MDA est l'élaboration de modèles indépendants de plates-

formes (PIM) et la transformation de ceux-ci en modèles dépendants de plates-formes
(PSM). Les techniques employées sont donc principalement des techniques de
modélisation et des techniques de transformation de modèles.
La stratégie MDA est de se concentrer sur l'élaboration de modèles de plus haut
niveau d'abstraction et de favoriser les approches transfomnationnelles paramétriques
vers les plates-formes techniques. Ceci signifie que l'on pourra, par exemple, définir
des modèles métier totalement indépendants des plates-formes techniques et générer
du code soit pour CORBA, soit pour Java/EJB, soit pour C#/DotNet, soit pour
XML/SOAP/WSDL, soit encore pour des compositions de ces différentes plates-
formes.
Le MDA se découpe en 4 principales couches (ou étapes) qui réfèrent à chaque fois à
des standards déjà adoptés par l'industrie ou en cours de normalisation.

254 de 273
 Rnanc*

Manufaeturing
t E-Commsree

Model
Architecture*

HMlthCar*

Mac*...

figure 4.1 : Architecture global de MDA [6]

Au cœur de MDA, on retrouve les technologies UML, MOF et CWM spécifiées par
l'OMG pour modéliser la logique métier de l'application. Ce modèle métier est
spécialisé ensuite dans une technologie middleware. On retrouve les standards actuels
tels que les EJBs, Corba, .NET et les WebServices. L'anneau extérieur du cercle
représente les services. Ceux-ci permettent par exemple de gérer la transaction, la
persistance, les événements.
Enfin, la couche spécifique au domaine prend place à la périphérie du noyau. Elle se
base sur les profiles UML et permet de proposer des frameworks spécifiques au
domaine d'application (Espace, Télécommunication, Mécanique, etc. ).

255 de 273
 Pmvasfre îrfla Ptatform- Domain
RKH*M
Nodet
UMLMwM

OWQ-timdttd Mfefc SwvkxM

Ftororm»
AppNcttton
UHLModel

Doploy, Hun
figure 4.2 : Dynamique générale de la mise au point d'une architecture MDA [6]

3. Le PIM - Platforme Indépendant Model

La première étape lors de la conception d'une application est de se concentrer sur

l'intérêt de l'application : la logique métier. Cette étape permet la mise au point de
l'intelligence du modèle, totalement spécifique à l'application, mais indépendante de la
technique. Dans un cycle de développement "en Y", le PIM est considéré comme
l'architecture métier. Elle est mise au point par un architecte spécialisé dans le
domaine de l'application. Pour mettre au point cette partie, trois standards sont utilisés

• UML : pour modéliser;

• MOF : pour méta-modéliser (par l'intermédiaire de XMI)
• CWM : pour modéliser les flux entre Datawarehouses et le traitement en temps réel
d'informations, tout en contrôlant les ressources.

256 de 273
Concrètement, l'architecte met au point ces diagrammes de classes, et il les
stéréotype en suivant le méta-modèle MDA, en vue de donner une sémantique aux
classes.

figure 4.3 : Exemple de modélisation UML d'un objet PIM [6]

De plus, l'utilisation d'UML comme moyen pour donner une sémantique MDA à des
objets est judicieuse car cette méthode de représentation est très complète et permet
de pousser loin la modélisation. On peut par exemple utiliser les pré/post condition par
l'intermédiaire de OCL.
Par comparaison, le format IDL promu par l'OMG pour Corba pour représenter
l'interface de classes indépendamment du langage, est moins concis et moins formel
(pas d'invariant, pas de contraintes sur la valeur "null", . . . ) .
Une fois le PIM mis au point, il devient ainsi bien plus facile de procéder à des
contrôles de cohérence sur le modèle que si on travaillait directement sur un modèle
spécifique à une plateforme.
En résumé, les PIMs (Platform Independent Models ) sont des modèles qui n'ont pas
de dépendance avec les plates-formes techniques (c'est-à-dire EJB, CORBA, DotNet,
XML, etc.). Les PIMs représentent par exemple les différentes entités fonctionnelles
d'un système avec leurs interactions, exprimées uniquement en termes de la logique
d'entreprise.

257 de 273
4. PSM - Platform Spécifie Model

Lorsque le PIM est en construit, la phase suivante est de générer le modèle décrit
dans des termes métiers vers une plate-forme spécifique de middieware. Au fur et à
mesure de l'évolution des outils de génération MDA, cette phase sera de plus en plus
automatisée. Elle aura à terme la même puissance qu'ont aujourd'hui les outils de
génération de code à partir de modèles UML.

<«ft))!tlAlr4«fhç<>>
S m i , , . S Mtelt laiincb hja.it

T" i

«L'UKHAlil«ti«<»
1 '
<
MWintH MHtM : ion|i« l»nj : ImwW

•en,li.h

-ML

figure 4.4 : Exemple de modèle PSM Corba [6]

La génération consiste à créer à la fois des éléments spécifiques à la plateforme cible

tels que les fichiers IDL en Corba, les descripteurs de déploiement XML en Java ou les
fichiers WSDL en .NET, mais également des modèles UML représentant les classes
du modèle métier dans le contexte d'un middieware.

En résumé, disons qu'à la différence des PIM, les PSM (Platform Spécifie Models) sont
dépendants de plates-formes techniques. Les PSM servent essentiellement de base à
la génération de code exécutable vers ces mêmes plates-formes.

5. du PIM vers le PSM

Comme annoncé plus haut, le MDA peut se résumer à l'élaboration de modèles

indépendants de plates-formes et à la transformation de ceux-ci en modèles
dépendants de plates-formes. Le principe de l'approche MDA consiste à passer des

258 de 273
PIM aux PSM pour préparer et faciliter la génération de code vers une plate-forme
technique choisie. Ce passage des PIM aux PSM est une transformation de modèles.
Le MDA identifie plusieurs types de transformations (voir figure 4.5 ) :
• PIM vers PIM : Ces transformations s'effectuent pour ajouter ou soustraire des
informations aux modèles. Le fait de masquer par exemple quelques éléments afin
de s'abstraire de détails fonctionnels est typiquement une transformation PIM vers
PIM. Dans l'autre sens, le passage du problème à la solution est la plus naturelle
des transformations PIM vers PIM. Il est important de noter que ces transformations
ne sont pas toujours automatisables.
• PIM vers PSM : Ces transformations s'effectuent lorsque les PIM sont
suffisamment complets pour pouvoir être mappés dans une plate-forme technique.
L'opération qui consiste à ajouter des informations propres à une plate-forme
technique pour permettre la génération de code est une transformation PIM vers
PSM. A l'heure actuelle, les plates-formes techniques visées sont DotNet, J2EE,
XML et CORBA. Il apparaît clairement que ce sont les règles qui permettent ces
transformations qui sont importantes et qui doivent être généralisées et
capitalisées. Ces transformations ont donc pour but d'être fortement automatisées.
• PSM vers PSM : Ces transformations s'effectuent lors des phases de déploiement,
d'optimisation ou de reconfiguration. Notons de plus qu'une unique transformation
PIM vers PSM n'est pas toujours suffisante pour permettre la génération de code, il
faudra alors parfois transformer les PSM en PSM en utilisant des formalismes
intermédiaires (exemple de passage d'UML à SDL puis de SDL à C++).
• PSM vers PIM : Ces transformations s'effectuent pour construire des PIM à partir
d'un existant. Même quand le patrimoine applicatif peut être représenté sous forme
de PSM, ces transformations sont assez difficiles à établir dans l'état de l'art actuel.
Elles sont pourtant nécessaires à considérer dans toute stratégie de migration.

La figure 4.5 présente les différentes transformations de modèles identifiées par

l'approche MDA. Il est important de noter que la génération de code n'est pas toujours
considérée comme une transformation de modèles même si certains font la distinction
entre PSM exécutables (le code) et PSM non exécutables.

259 de 273
 6

figure 4.5 : Opérations sur les modèles dans le MDA [6]

6. ARCHITECTURE STRATIFIEE

La distinction entre les PIM et les PSM est plutôt d'ordre méthodologique. Il est
important de noter que cette distinction n'est pas la seule. En effet, les modèles
manipulés dans le MDA sont de natures très diverses. Il y a bien sûr les modèles
d'objets métier, les modèles de processus ou de workflow, les modèles de règles mais
aussi les modèles de service, de qualité de service, les modèles de plate-forme, les
modèles de transformation, les modèle de tests, les modèles de mesure, etc. Derrière
le recensement en cours de tous ces modèles (la cartographie générale du MDA) se
profile un projet ambitieux et à long terme de définition d'un cadre générique de
conception et de maintenance des systèmes d'information. Afin d'organiser et de
structurer tous ces modèles, l'OMG a défini une architecture à quatre niveaux (figure
4.6):
• Le niveau MO est le niveau des données réelles. Il est composé des informations
que l'on souhaite modéliser. Ce niveau est souvent considéré comme étant le
monde réel.
• Le niveau M1 est composé de modèles d'information. Lorsque l'on veut décrire les
informations de MO, le MDA considère que l'on fait un modèle appartenant au
niveau M1. Typiquement, un modèle UML appartient au niveau M1. Tout modèle
est exprimé dans un langage unique dont la définition est fournie explicitement au
niveau M2.
• Le niveau M2 est donc composé de langages de définition des modèles
d'information, appelés aussi méta-modèles. Typiquement, le méta-modèle UML qui
est décrit dans le standard UML appartient au niveau M2; il définit la structure
interne des modèles UML. Notons au passage que le concept de profil UML qui
permet d'étendre le méta-modèle UML est aussi considéré comme appartenant au

260 de 273
 niveau M2. Un méta-modèle définit donc un langage de modélisation spécifique à
un domaine et un profil définit un dialecte (une variante) de ce langage.
Le niveau M3 qui est composé d'une unique entité qui est le langage unique de
définition des méta-modèles, aussi appelé le méta-méta-modèle ou le MOF (Meta-
Object Facility). Le MOF définit la structure de tous les méta-modèles qui se
trouvent au niveau M2. Le MOF est réflexif, c'est-à-dire que la description du MOF
s'applique au MOF lui-même, ce qui permet de dire que le niveau M3 est le dernier
niveau de l'architecture. Le niveau M3 correspond donc aux fonctionnalités
universelles de modélisation logicielle, alors que le niveau M2 correspond aux
aspects spécifiques des différents domaines, chaque aspect particulier étant pris en
compte par un méta-modèle spécifique.

A/l Le MOF

Le méta-modèle UML et autres MMs

méta-modèle

Des modèles UML et d'autres

modèle

^Différentes utilisations
Mo, te monde réel de ces modèles

Figure 4.6 : L'architecture à 4 niveaux [8]

Dans cette architecture, les PIM et les PSM appartiennent au niveau M1. Leurs
structures sont définies par des méta-modèles (ou profils) qui appartiennent au niveau
M2. Le MOF permet de définir de façon homogène, tous ces méta-modèles. Le MDA
ne traite pratiquement pas du niveau MO.
Il faut enfin insister sur le fait que les niveaux qui viennent d'être décrits n'ont rien à
voir avec des niveaux d'abstraction ou de machines virtuelles comme on peut en
trouver dans les piles ISO/OSI ou TCP/IP par exemple. Ce sont des niveaux de méta-
modélisation différents de ce que l'on nomme parfois la méta-programmation.

261 de 273
7. Les défis de l'OMG

Le MDA est un ambitieux projet qui débute et qui va certainement durer plusieurs
années. Il reste encore beaucoup de travail à faire pour clarifier la proposition [10].
Trois axes par rapports auxquels il est possible de recenser les principaux défis à
relever pour le MDA :

• D'un point de vue technique, il semble que le plus gros défi à relever soit celui de la
transformation de modèles, ou plus généralement de la manipulation de modèles
(séparation et tissage d'aspects, fusion de modèles par exemple). Il est en effet
important de pouvoir capitaliser sur ces opérations. Il faudra donc être capable de
les modéliser comme nous modélisons aujourd'hui les systèmes d'information.
Plusieurs initiatives commencent à émerger et proposent des approches générales
pour modéliser les transformations de modèles. L'OMG a d'ailleurs publié un RFP
(Request For Proposai) pour qu'un standard soit élaboré à partir de ces initiatives.
La communauté W3C/XML possède avec XSLT un tel outil pour transformer les
documents et les schémas. La communauté OMG/MOF/UML est en train de se
définir le sien. La mise en correspondance de ces deux standards devrait être
possible.
• D'un point de vue méthodologique, il semble que le plus gros défi soit de définir
quelles sont les méthodes applicables au MDA. Il semble que l'évolution du cycle
en « Y » en soit une. La branche de gauche correspondrait aux PIM. La branche de
droite correspondrait à la description des plates-formes techniques. La jointure de
ces branches correspondrait à la transformation des PIM en PSM. La branche du
bas correspondrait aux PSMs et à leur transformation vers du code. Approfondir le
MDA revient donc à "revisiter le cycle en Y", en explicitant à chaque fois de façon
précise les informations sur lesquelles on travaille par un méta-modèle spécifique.
• D'un point de vue stratégique, il paraît clair que le défi à relever consiste à savoir
comment intégrer le MDA dans l'entreprise. Il faut pour cela pouvoir répondre à
plusieurs questions comme savoir entre autres quels sont les avantages du MDA
par rapport aux approches existantes (objets, composants, web services), quelles
sont les compétences à posséder pour utiliser le MDA, quels sont les métiers qui
sont touchés par le MDA, etc. Ces questions ont pour but de permettre le calcul du

262 de 273
 retour sur investissement d'un passage au MDA. Il faudra donc bien en évaluer les
bénéfices potentiels.

Et pour conclure, une citation assez significative sur l'enjeu MDA de Desmond DSouza,
Kinetium ( ftp://ftp. orna, ora/pub/docs/ab/O1 -03-02. pdf) :

« . . . T h e MDA initiative, if successful, will define a large space populated by a huge

number of models. There has to be some cohérent structure on this space of models,
providing a rational and consistent way to locate, partition, and relate thèse models.
This structure is the essence of the "A" in "MDA". »

RÉFÉRENCES MOF ET MDA

[1"| François Pennaneac'h [novembre 2001 IFSIC] : UML : de l'action à la réflexion.

[2] dMOF 1.1, http://www.dstc.edu.au/Products/CORBA/MOF/
[3] http://universalis.elibel.tm.fr/index.html
[4] M3J Project, http://www-src.lip6.fr/meta/Proiets/M3J/
[5] www.devreference.net
[6] Soley, R. and the OMG staff Model-Driven Architecture. OMG document disponible à [1]
www.omq.org , novembre 2000.
[7] http://membres.lycos.fr/mda44/
[8] OMG/MOF, Meta Object Facility (MOF) Spécification, OMG Document formal/2000-04-03,
mars 2000, http://www.omg.org/technology/documents/formal/mof.htm.
[9] OMG/UML, Unified Modeling Language (UML), version 1.4, OMG Document formai/2001 -
09-67, septembre 2001, http://www.omg.org/cgi-bin/doc7formal/01-09-67
[10] D'Souza D., Model-Driven Architecture and Intégration - Opportunités and
Challenges, mars 2001, ftp://ftp.omg.org/pub/docs/ab/01-03-02.pdf.

263 de 273