2009

UQAM
Département
d’informatique
Doctorat en
informatique cognitive

Remis au professeur
Modélisation UML
Hakim Lounis par
d’un EIAH pour
Albert Lejeune
faciliter
DIC 9250
l’apprentissage des
EAAR 06.12.2009
 Modélisation UML d’un EIAH pour faciliter l’apprentissage des EAAR

Plan du travail

PLAN DU TRAVAIL 2

CONTEXTE 4

DÉFINITION DE EIAH 5

DÉFINITION DE EAAR 5

DÉFINITION DE TEST D’HYPOTHÈSE 6

L’IMPORTANCE DE LA MODÉLISATION ORGANISATIONNELLE : L’APPORT DE OM 7

LE PROCESSUS DE LA MODÉLISATION OM 8
LA MOLÉCULE PROCESSUS 9

LES ÉTAPES DE MODÉLISATION OM 10

1. LA BASE DE RÉFÉRENCE 10
2. LA PORTÉE DE L’INTERVENTION 10
3. LA COUCHE DE SPÉCIFICATION 11
4. LA COUCHE D'ALIGNEMENT 11
5. LA COUCHE DE RÉALISATION 11

MODÉLISATION UML D’UN EIAH POUR EAAR 12

CAS D’UTILISATION (1): MODÉLISER LE PROCESSUS AS IS ET TO BE 13

CAS D’UTILISATION (2) : GÉRER LE TEST D’HYPOTHÈSE 16
LE DIAGRAMME DE CLASSES 18
DIAGRAMME DE CLASSE (PARTIE 1): MODÉLISER ET GÉRER 18

A Lejeune UML DIC 9250 – A2009 Page 2

DIAGRAMME DE CLASSE (PARTIE 2): TRANSFORMER ET APPRENDRE 19
DIAGRAMME DE COLLABORATION 20
DIAGRAMME D’ÉTATS POUR LES PROCESSUS AS IS – TO BE 20

DISCUSSION ET CONCLUSION 21

RÉFÉRENCES UTILISÉES 22

A Lejeune UML DIC 9250 – A2009 Page 3

Contexte

Pour innover rapidement, la littérature récente met l’emphase sur des expériences
d’affaires bien ciblées et structurées tout en étant conformes à la démarche scientifique
de test d’hypothèse (Davenport, 2009). Selon Davenport, ces expériences d'affaires
deviennent une nouvelle façon d'organiser les activités de recherche et de
développement, de démarrer une nouvelle entreprise, d’innover en termes de produits
ou de services, ou de modifier tout processus d'affaires dans l'entreprise. Mais d’où
viennent les hypothèses à la base de ces expériences? Probablement de propositions
d’idées qui émergent d’un collectif quelconque (cercle de qualité, équipe de travail,
équipe de projet, communauté de pratique, ‘focus group’ etc..). Ces propositions ont
été triées, criblées et ordonnées vraisemblablement avec l’aide d’un intrapreneur expert
(dans les grandes organisations) ou directement par l’entrepreneur, qui,
particulièrement dans le cas de la nouvelle start-up, impose et s’impose un cycle rapide
de tests d’hypothèses.

Avec Drucker (1994), nous pensons que les firmes qui varient, étendent, multiplient et
recoupent les contextes de test d’hypothèses et d’expériences d’affaires sont plus à
même d’anticiper l’environnement de la firme.

Rappelons que les enjeux tactiques des EAAR sont des enjeux éminemment
stratégiques. Pour Brijnjolfson et Schrage (2009), ces expériences vont devenir à
la fois plus présentes et déterminantes étant donné le potentiel croissant des
technologies de l’information (TI) permettant de reproduire ces expériences à l’échelle
d’une grande organisation ou d’un réseau organisationnel étendu. Les implications
sont grandes notamment sur le fonctionnement de la fonction R&D. Les Google
de ce monde se départissent des méthodes traditionnelles de R&D: les
propositions innovantes ne viennent plus de 3 ou 4 gurus mais de 50 ou 60
expériences menées à l'échelle de la planète. Dans ces firmes, on ne parle plus
d'innover dans le futur, mais de mener des expériences sur une base continue.

Ce papier vise à effectuer une première modélisation UML d’un environnement

informatisé pour l’apprentissage humain (EIAH) permettant de faciliter l’apprentissage
individuel et organisationnel lors de la réalisation de tests d’hypothèses portant sur des
processus d’affaires. Dans cette modélisation UML, l’EIAH devra permettre le passage
du concret à l’abstrait, c'est-à-dire du processus existant (AS IS) au processus futur (TO
BE) au moyen de la méthode OM (Organizational Modelling) d’aide à la visualisation de

A Lejeune UML DIC 9250 – A2009 Page 4

l’architecture organisationnelle. Ce travail comporte de nombreuses limites : le
processus de design organisationnel est considéré comme un processus limité dans
l’espace et dans le temps (One Shot), les interventions éventuelles de personnes non
expertes ne sont pas modélisées ni la possibilité d’un travail collectif, sous forme de
communauté de pratique. Nous reprendrons brièvement ces points dans la discussion.

Ce papier est organisé de la façon suivante : nous commençons par placer les définitions
couramment utilisées dans ce texte comme EIAH, EAAR, test d’hypothèse et méthode
OM de modélisation. Ensuite, nous présentons la modélisation UML de la façon
suivante : présentation des cas d’utilisation, présentation des classes d’objets et
diagramme de collaboration et d’états. Nous concluons par une brève discussion.

Définition de EIAH
Pierre Tchounikine (2009) définit ainsi un environnement informatisé pour
l’apprentissage humain (EIAH) :

Dans cette définition, SPI est l’acronyme de situation pédagogique informatisée et SAI
l’acronyme de situation d’apprentissage informatisée. Dans le cadre de ce travail, nous
n’élaborons pas sur l’intention pédagogique liée à notre modèle UML.

Définition de EAAR
Prenons un exemple. Chez Merck, des défis liés à l'information sont omniprésents
tout au long des activités de découverte de nouveaux médicaments. Traduire
efficacement le potentiel des nouvelles TI innovatrices pour offrir de nouvelles
capacités de R&D nécessite de combler les écarts entre, d’une part, les
innovateurs externes en TI et, d’autre part, la R&D interne et le personnel

A Lejeune UML DIC 9250 – A2009 Page 5

informatique. Pour pallier à cette faiblesse, Merck Research Laboratories (MRL) a
créé un nouveau groupe appelé MRL Information Technology Innovation qui
construit ce que nous appelons des EAAR, des expériences d’affaires agiles et rapides .
Le groupe identifie les nouvelles technologies d'information les plus prometteuses
et utilise ses connaissances privilégiées des besoins d’affaires actuels et émergents
de MRL pour mettre au point des applications. Les applications de ces nouvelles
technologies doivent répondre aux défis d’affaires de Merck, sous forme de courtes
expériences agiles (EAAR). Pour toute initiative impliquant l'informatique innovante,
une hypothèse est développée. Son test va nécessiter la conception et l'exécution
d'une expérience.

Définition de test d’hypothèse

Bien sûr, pour Davenport (2009), la méthode scientifique n'est pas nouvelle, ni son
application dans le monde des affaires. C’est la disponibilité à grande échelle de logiciels
qui permettent de fonder des expériences scientifiquement fondées qui ne nécessitent
plus l’intervention d’un docteur en statistiques. Appliquer ces tests d’affaires a jusqu'à
récemment été une entreprise majeure.

Figure 1 : les 6 étapes d’un test d’hypothèse

Les étapes d’un test d’hypothèse dans le milieu des affaires sont les suivantes : 1. Créer
ou affiner l’hypothèse 2. Concevoir le test 3. Exécuter le test 4. Analyser le test 5.
Planifier la diffusion et 6. Diffuser à l’échelle de la firme.

A Lejeune UML DIC 9250 – A2009 Page 6

Pour Davenport (2009), le test d’hypothèse n’est utile que dans des situations où les
résultats souhaités sont définis et mesurables. Ainsi quand un nouveau programme de
formation est proposé, avant de tester son efficacité, la firme doit identifier un objectif
(tel que «Nous voulons augmenter les ventes croisées»), et elle devra être capable de
mesurer ce changement. Les ventes et les variations des taux de conversion sont
fréquemment utilisées comme variables dépendantes dans les tests et sont mesurées
de manière fiable à des fins distinctes. D’autres résultats, tels que la satisfaction des
clients et l’engagement des employés, exigent plus d'efforts et imposent des mesures à
caractère invasif. Les tests sont plus fiables quand de nombreuses situations ou sites
équivalents peuvent être observés. Cet pourrait signifier sites physiques, comme avec
de magasins Sears, ou cela pourrait signifier des réglages plus éphémères, comme les
versions successives d’un site web.

Les distributeurs au détail et chaînes de restaurants comptent parmi les premiers et les
plus grands utilisateurs de tests. Tirer des inférences statistiques d’un petit nombre de
sites d'essai est beaucoup plus difficile et représente le grand défi de l’approche «tester
et apprendre ». Enfin, les tests formels n'ont de sens que si une hypothèse logique a été
formulée à propos de la façon dont une intervention proposée aura une incidence sur
une entreprise.

L’importance de la modélisation organisationnelle : l’apport de OM

Bien qu'il semble possible de se passer d’hypothèse, de faire juste un changement, de
prendre du recul et d’observer ce qui arrive, cette approche conduira inévitablement à
une hypothèse, et souvent on réalisera qu'elle aurait pu être formulée à l'avance et
testée avec plus de précision. C’est toute la question du passage du concret à l’abstrait,
et du retour de l’abstrait vers le concret. Poser une hypothèse exige d’avoir une
représentation et, plus encore, de travailler au niveau symbolique. C’est exactement la
réflexion que se font, par exemple, des professeurs de mathématiques i. Dans l’exemple
donné sur ce site, des blocs de couleur figurent le niveau concret, des dessins – des
représentations ordonnées - de ces blocs représentant un niveau intermédiaire, et,
finalement, le niveau abstrait est le niveau symbolique qui permet de modéliser et
résoudre des problèmes. De la même façon, dans notre démarche, OM nous permet de
développer des représentations et ensuite, de travailler à un niveau abstrait à l’aide de
l’approche objet appliquée au fonctionnement des molécules organisationnelles.

Mais cette modélisation ne portent pas que sur les aspects physiques et formels (hard),
elle va porter aussi sur les aspects intangibles et informels (soft). Ainsi, à l’époque de
Taylor et de la production à la chaîne, la conception physique du travail représentait

A Lejeune UML DIC 9250 – A2009 Page 7

l’essentiel d’une architecture organisationnelle. Aujourd’hui, dans les organisations
apprenantes, la source de la création de valeur réside dans des choses qui ne peuvent
être explicitement conçues et formulées, comme les idées, le potentiel d’un produit ou
d’un service ou encore la trajectoire d’une organisation qui se transforme.

Enfin, beaucoup de dirigeants comprennent que si les organisations peuvent démontrer

certaines caractéristiques comme l’agilité, la qualité, et la vitesse d’exécution, ces
caractéristiques sont émergentes. Elles sont issues d’un pattern, d’un patron
d’arrangements et d’alignements entre des domaines organisationnels tel que
l’information, les processus, la culture, les personnes et l’apprentissage (Morabito et al.,
1999). Pour ces dirigeants, une nouvelle compétence est exigée : la pratique de
l’architecture qui consiste à démonter une organisation en ses composantes
fondamentales afin d’en comprendre les qualités émergentes.

Le processus de la modélisation OM
Se lancer dans un processus de design à l’aide d’OM est d’abord un exercice de
visualisation (Morabito et al., 1999, p.131). La visualisation se compare à la composition
d’une symphonie ou à la réalisation d’une peinture. L’artiste démarre à l’aide d’une
image mentale et se lance dans un processus de création où le rendu est visualisé même
s’il n’est pas formé entièrement. Au fur et à mesure que l’artiste complète l’image, la
composition commence à prendre forme. L’artiste intervient avec son pinceau en
accord avec l’image alors que la forme résultante moule l’image en retour. À la fois
planifiée et émergente, l’image peinte est un produit de la visualisation.
La visualisation est élaborée, de façon artisanale, pour tenir compte des caractéristiques
émergentes désirées, de la culture organisationnelle, des domaines organisationnels et
de la stratégie de changement. Tous ces éléments représentent ensemble l’architecture
organisationnelle. Le succès de celle-ci est largement déterminé par sa capacité de
réaliser le moulage du processus de visualisation et d’implémentation.
La visualisation est le mécanisme qui permet de concevoir une architecture
organisationnelle de façon radicale. Elle permet à l'architecte organisationnel d'avoir
une vision globale de l’organisation, quoique des domaines de décision particuliers
soient implémentés de façon incrémentale, sous forme de domaines ou « molécules »
organisationnels spécifiques. Les molécules aident l’architecte organisationnel à
travailler sur un problème spécifique incluant de multiples facettes de l’organisation.
Morabito et al. (1999, pp.78-93) expriment le concept de molécule organisationnelle à
partir de la métaphore de la molécule d’eau. En fait, l’eau se décompose en deux

A Lejeune UML DIC 9250 – A2009 Page 8

éléments soient l’hydrogène et l’oxygène (H2O). Mais c’est le principe de combinaison
d’éléments qui une fois assemblée fait émerger la molécule. De la même façon, les
composants du processus (personnes, structure, information et outils) collaborent pour
former – faire émerger- le processus qui peut alors être défini par des spécifications.

La molécule Processus
Les processus d’affaires sont une source d’avantage concurrentiel. Dans l’approche OM,
le processus d’affaires générique, représenté par la molécule Processus, n’est pas un
élément tangible, mais plutôt une abstraction des interrelations entre les personnes, les
structures de travail, l’information et les outils comme illustré dans la Figure 2.

Dans OM (Morabito et al., 1999, pp.169-198), il existe une séparation entre la

spécification et l’implémentation. La spécification se fait au niveau du Processus alors
que l’implémentation se fait via les composantes Personne, Structure, Information et
Outil. C’est au niveau de l’implémentation que des caractéristiques désirées du
processus émergent.

Figure 2 : la molécule Processus et son contrat selon OM

Un processus n’est pas simplement une orchestration des flux de tâches, mais aussi le
reflet des principes de gestion et de la culture d’une organisation. La formulation d’un
processus, selon l’approche OM, est une démarche architecturale qui représente le
cœur de la transformation organisationnelle. Cette démarche est une séquence
composée de la caractérisation, de la transformation, de la spécification, du design et
l’implémentation de processus :

A Lejeune UML DIC 9250 – A2009 Page 9

  La caractérisation implique le positionnement d’un processus par rapport à des
paradigmes de gestion, qui peuvent comprendre des construits et modèles
associés à la théorie organisationnelle comme la chaîne de valeur de Porter
(Porter, 1985) pour guider la conception d’un processus.
 La transformation représente le contexte du changement organisationnel dans
lequel un processus est formulé. La réingénierie, l’amélioration continue, la
gestion intégrale de la qualité et l’alignement stratégique sont des exemples
communs de changements organisationnels.
 La spécification est l’étape qui vise à spécifier des contrats de comportements
organisationnels désirés pour un processus et à décomposer un processus.
 Le design vise à raffiner la situation désirée et la coordination entre les unités de
travail d’un processus.
 L’implémentation représente la mise en œuvre des spécifications du design.
Ces étapes forment les liens entre un processus existant (AS IS) et un processus souhaité
dans le futur (TO BE). Ces liens détaillés entre les processus AS IS et TO BE ne seront pas
modélisés dans le cadre de ce premier travail.

Les étapes de modélisation OM

1. La base de référence
Le but premier de la création d'une base de référence (Morabito et al., 1999, pp.112-
113) est de faire l’analyse du type d'organisation actuel et futur que l’architecte
organisationnel a l'intention de concevoir ou d’améliorer. La première tâche de
l’architecte consiste à identifier l'invariant socioculturel1 de l’organisation étudiée. La
deuxième tâche consiste à identifier l'invariant spécifique de cette organisation.

2. La portée de l’intervention
En OM, la deuxième étape de visualisation d’une architecture est la détermination de la
portée de l’intervention c’est à dire la désignation des molécules qui doivent intervenir
dans le processus de visualisation (Morabito et al., 1999, pp.113-115). Faut-il visualiser
toute l'organisation et multiplier les domaines analysés (culture, stratégie, structure,
processus, apprentissage, personnes, information, etc.) ou faut-il cibler un ou deux
domaines organisationnels en particulier ? Le choix de la portée de l'intervention
dépend des objectifs poursuivis par le gestionnaire EAAR et l’architecte organisationnel.

1
L’invariant socioculturel (ex : l’individualisme en Amérique du Nord) définit culturellement la société dans laquelle
évolue une organisation.

A Lejeune UML DIC 9250 – A2009 Page 10

3. La couche de spécification
La couche de spécification (Morabito et al., 1999, pp.116-117) est caractérisée par la
définition précise du comportement des domaines organisationnels ou molécules. Elle
consiste à spécifier le comportement d’un domaine à travers un contrat et d'en
identifier les composantes. Le contrat comprend des pré-conditions qui sont la situation
avant l'exécution, des post-conditions qui sont la situation après l'exécution, les
invariants qui sont l’ensemble des règles à respecter durant l'exécution et le
déclencheur qui est l'événement initiant l'exécution du contrat.

4. La couche d'alignement
Avec OM (Morabito et al., 1999, pp.117-118), l'alignement doit se faire à plusieurs
niveaux dans l'organisation. Le premier niveau est celui de la molécule
organisationnelle. Tous les éléments constitutifs d’une molécule doivent se renforcer
mutuellement afin que, par émergence, le comportement émergent soit un patron qui
présente les caractéristiques de performance souhaitées.

Le deuxième niveau d'alignement se situe entre les molécules. Il est important de savoir
dans quelle mesure les molécules de l'organisation se supportent mutuellement et
quelle est la solidité du treillis qu'elles forment de par leurs relations réciproques. Les
liens entre les molécules doivent être serrés pour procurer le maximum d'alignement
possible. Il est important de souligner ici l'importance de l'alignement de chaque
molécule par rapport à la molécule "Culture". En effet, selon l'OM, la culture
organisationnelle est la première source d'alignement tacite et contractuel. Sa force
d'alignement est tellement puissante qu'elle impose ses contraintes au reste des
molécules.

Le troisième niveau d'alignement concerne l'organisation et son environnement. Du

point de vue systémique, une organisation est un tout organique. Sa réaction par
rapport à l'environnement est caractérisée par l'ensemble de ses comportements
générés par l'agrégation de ses composants. L'alignement à ce niveau est un alignement
dynamique, car l'organisation, modélisée comme un patron résultant des patrons
d'alignement, doit être agile par rapport à son environnement volatile

5. La couche de réalisation
En OM (Morabito et al., 1999, pp.118-120), la cinquième étape de visualisation d’une
architecture organisationnelle est l'opérationnalisation du comportement de
l'alignement par la réalisation du modèle conçu dont les spécifications ont été définies
sous forme de contrats et dont les différents niveaux d'alignement ont été validés dans
les étapes précédentes. Étant donné que le but ultime d’OM est d'opérationnaliser les

A Lejeune UML DIC 9250 – A2009 Page 11

domaines organisationnels via les contrats pour donner à l'organisation les
comportements souhaités, l'étape de réalisation permet effectivement cette
opérationnalisation en définissant, en termes de dimensions temporelle et séquentielle,
les propriétés des molécules correspondantes.

Modélisation UML d’un EIAH pour EAAR

Le modèle des cas d’utilisation est commenté ici en deux parties. La partie supérieure
du modèle Use Case UML (généré par Altova© 2009) présente la problématique de la
modélisation organisationnelle : comment décrire un processus existant devant faire
l’objet d’un changement (et devenir le processus TO BE) en 6 étapes? Deux acteurs vont
utiliser le EIAH pour EAAR : l’architecte organisationnel et un système qui peut être une
application développée sous un éditeur d’ontologies comme Protégé pour maintenir
une ontologie formelle de molécules et contrats de l’entreprise étudiée.

La cas principal se nomme : Modéliser le processus AS IS et TO BE, à l’aide de la relation

include, six sous-cas représentent les six couches du processus de modélisation OM. Le
sous-cas Layer 2 accède aux molécules organisationnelles et le sous-cas Layer 3 accède
aux contrats.

Figure 3 : Le diagramme des cas d’utilisation (partie supérieure)

La partie inférieure du modèle présente, à gauche, les acteurs stratégiques : le manager

stratégique qui peut autoriser un budget pour effectuer une EAAR, le gestionnaire de
cette EAAR et le système organisationnel de planification stratégique qui va veiller à la
diffusion des résultats à l’échelle de l’organisation. Sur la droite, les acteurs reliés à la
problématique de l’apprentissage : le centre virtuel d’apprentissage, un participant aux
A Lejeune UML DIC 9250 – A2009 Page 12
EAAR (l’utilisateur type des résultats des tests) et un référentiel de processus. Le cas
principal d’utilisation est ici la gestion d’une EAAR – Gérer le processus de test
d’hypothèse - EAAR - comprenant les étapes de 1 à 5 vues plus haut dans le texte pour
définir un test d’hypothèse.

Figure 4 : Le diagramme des cas d’utilisation (partie inférieure)

Cas d’utilisation (1): Modéliser le processus AS IS et TO BE

Cas d’utilisation : Modéliser le processus S IS et TO BE (sans utiliser include pour les sous-cas
d’utilisation)

Acteur(s) : Architecte organisationnel

But : Produire un modèle du processus sur lequel porte le test d’hypothèse (AS IS) et sa cible (TO
BE)
Déclencheur : Autorisation d’un budget EAAR sur ce processus
Préconditions : BD des molécules OM à jour, BD des contrats OM à jour, mandat EAAR défini et
numéro de processus attribué, architecte disponible
Postconditions : Modèle OM du processus AS IS, modèle OM du processus TO BE, mise à jour
des BD molécules et contrats.
Type : Essentiel, primaire

A Lejeune UML DIC 9250 – A2009 Page 13

 Actions Acteur : Architecte Réponses système
organisationnel
1. Demande l’ouverture d’une session de
modélisation OM pour le processus numéro xx

2. Affiche l’écran de travail Layer 1 AS IS

3. Complète la saisie de Layer 1 AS IS

4. Sauvegarde les données de Layer 1 AS IS

5. Affiche l’écran de travail Layer 1 TO BE

6. Complète la saisie de Layer 1 TO BE

7. Sauvegarde les données de Layer 1 TO BE

8. Affiche l’écran de Layer 2 AS IS

9. Affiche l’accès aux molécules OM déjà décrites

10. Complète la saisie de Layer 2 AS IS

11. Sauvegarde les données de Layer 2 AS IS

12. Met à jour la bibliothèque de molécules

13. Affiche l’écran de Layer 2 TO BE

14. Affiche l’accès aux molécules OM déjà décrites

15. Complète la saisie de Layer 2 TO BE

16. Sauvergarde les données de Layer 2 TO BE

17. Affiche l’écran de Layer 3 AS IS

18. Affiche l’accès aux contrats OM déjà décrits

19. Complète la saisie de Layer 3 AS IS

20. Sauvegarde les données de Layer 3 AS IS

21. Affiche l’écran de Layer 3 TO BE

22. Affiche l’accès aux contrats OM déjà décrits

23. Complète la saisie de Layer 3 TO BE

24. Sauvegarde les données de Layer 3 TO BE

A Lejeune UML DIC 9250 – A2009 Page 14

 25. Sauvegarde les nouveaux contrats

26. Affiche l’écran de Layer 4 AS IS

27. Complète la saisie de Layer 4 AS IS

28. Sauvegarde les données de Layer 4 AS IS

29. Affiche l’écran de Layer 4 TO BE

30. Complète la saisie de Layer 4 TO BE

31. Sauvegarde les données de Layer 4 TO BE

32. Affiche l’écran de Layer 5

33. Complète la saisie de Layer 5

34. Sauvegarde les données de Layer 5

35. Affiche l’écran de Layer 6

36. Complète la saisie de Layer 6

37. Sauvegarde les données de Layer 6

38. Envoie un message de fin de session

Cas d’utilisation : Modéliser le processus AS IS et TO BE (en utilisant include pour les sous-cas
d’utilisation)

Acteur(s) : Architecte organisationnel

But : Produire un modèle du processus sur lequel porte le test d’hypothèse (AS IS) et sa cible (TO
BE)
Déclencheur : Autorisation d’un budget EAAR sur ce processus
Préconditions : BD des molécules OM à jour, BD des contrats OM à jour, mandat EAAR défini et
numéro de processus attribué, architecte disponible
Postconditions : Modèle OM du processus AS IS, modèle OM du processus TO BE, mise à jour
des BD molécules et contrats.
Type : Essentiel, primaire

A Lejeune UML DIC 9250 – A2009 Page 15

 Actions acteur: Réponses système

Architecte organisationnel

1. Demande l’ouverture d’une session de modélisation

OM

2. Affiche le menu: Layer 1, Layer 2, Layer 3, Layer 4,

Layer 5, Layer 6

3. Choisit un item du menu: Layer 1

4. Propose Layer AS IS ou Layer 1 TO BE

5. Effectue son choix et effectue la saisie des données

AS IS ou TO BE

6. Sauvegarde les données et affiche le menu: Layer 1,

Layer 2, Layer 3, Layer 4, Layer 5, Layer 6

Voir 3.

Cas d’utilisation (2) : Gérer le test d’hypothèse

Cas d’utilisation : Gérer le processus de test d’hypothèse - EAAR (en utilisant include pour
les sous-cas d’utilisation)

Acteur(s) : Manager EAAR

But : Suivre et documenter les étapes du déroulement d’un test d’hypothèse
Déclencheur : Autorisation d’un budget EAAR sur ce processus
Préconditions : Modélisation OM du Processus AS IS et TO BE engagée, gestionnaire EAAR
affecté
Postconditions : documentation de hypothèse finalisée, test conçu, test exécuté, test analysé et
de diffusion planifiée
Type : Essentiel, primaire

A Lejeune UML DIC 9250 – A2009 Page 16

 Actions acteur: Réponses système

Architecte organisationnel

1. Demande l’ouverture d’une session de gestion d’une

EAAR

2. Affiche le menu: 1. Affiner l’hypothèse, 2. Concevoir

le test, 3. Exécuter le test, 4. Analyser le test, 5.
Planifier la diffusion

3. Choisit un item du menu: 1. Affiner l’hypothèse

4. Propose Comparaison visuelle et textuelle OM

Processus AS IS - TO BE (2 écrans) avec Affichage du
menu: 1. Base de référence, 2. Portée de l’intervention,
3. Couche de spécification, 4. Couche d’alignement, 5.
Réalisation

5. Effectue son choix et saisit les données (Affiner

l’hypothèse) dans le champ réservé

6. Sauvegarde les données et affiche le menu: 1. Affiner

l’hypothèse, 2. Concevoir le test, 3. Exécuter le test, 4.
Analyser le test, 5. Planifier la diffusion

Voir 3.

A Lejeune UML DIC 9250 – A2009 Page 17

Le diagramme de classes
Diagramme de classe (partie 1): Modéliser et gérer

Figure 5 : Le diagramme de classes (partie supérieure)

Le diagramme de classes est présenté en deux parties pour des raisons de commodité.
La partie supérieure est construite autour de deux grandes classes : le TestHypothèse et
le ModèleOMProcessus. La première de ces deux classes est une composition des 5
étapes du déroulement d’un test d’hypothèse, la deuxième est une collection des 6
étapes de la modélisation OM. La classe processus est associés avec le test
d’hypothèse : cela permet de décrire le processus et de distinguer ses associations avec
le processus AS IS et le processus TO BE.

A Lejeune UML DIC 9250 – A2009 Page 18

Diagramme de classe (partie 2): Transformer et apprendre

Figure 6 : Le diagramme de classes (partie inférieure)

La partie inférieure du modèle exploite la capacité de OM de modéliser les changements

‘top-down’ ou radicaux vs les changements ‘bottom-up’ ou incrémentaux. Ainsi la classe
ProcessTOBERadical est associée avec la classe ProcessusASIS au niveau des
spécifications alors que la classe ProcessTOBEIncrémental est associée avec les classes
Personnes, Structure, Information et Outils qui sont une composition de la classe
Processus ASIS.

A Lejeune UML DIC 9250 – A2009 Page 19

Diagramme de collaboration
Le diagramme suivant présente la façon dont les différents acteurs sont impliqués dans le cas
d’utilisation Modéliser OM Processus AS IS-TO BE. Une fois reçue l’autorisation de démarrer
une EAAR, le gestionnaire EAAR va circonscrire le processus à améliorer et envoyer cette
description à l’architecte organisationnel (AO). AO va fournir un modèle OM du processus AS IS
à l’architecte organisationnel qui va lui renvoyer sa vision du processus TO BE. AO va retourner
un modèle OM du processus TO BE. Un certain nombre d’itérations pourrait être envisagé.

Figure 7 : Le diagramme de collaboration

Diagramme d’états pour les Processus AS IS – TO BE

Le point de départ est l’observation d’un écart de performance sur un des processus clés
de la compagnie. Cet écart peut provenir d’un système de veille (Benchmarking) ou
d’une volonté de développer un avantage concurrentiel dans un ensemble d’activités
génératrices de valeur. Cependant la mise en route du EIAH pour EAAR ne se fait
qu’avec une autorisation budgétaire, accordée par un manager stratégique, visant à
corriger un manque de performance sur un processus défini. À travers la modélisation
OM, ce processus devient un Processus AS IS OM susceptible de recevoir la vision du
manager EAAR pour créer un processus futur, un processus TO BE. C’est le passage du
A Lejeune UML DIC 9250 – A2009 Page 20
concret à l’abstrait grâce à une représentation. Le processus OM TO BE abstrait va
maintenant devoir être instancié. Le système offre le choix d’une approche radicale ou
incrémentale à cette instanciation. Si l’approche est incrémentale, elle portera sur l’une
ou plusieurs des composantes du processus, à savoir : personnes, structure, information
et outils. Si le choix est radical, les nouvelles spécifications sont imposées, surtout par
automatisation accrue. Une mesure de performance est effectuée par la suite : sans
délai pour l’automatisation, avec un délai (ex : un mois) pour un changement
incrémental. Si l’écart est corrigé, la séquence est terminée pour le processus
considéré.

Figure 8 : Diagramme d’états pour les Processus AS IS – TO BE

Discussion et conclusion

Comme annoncé dans l’introduction, nous avons négligé dans ce premier modèle UML
d’un EIAH pour EAAR les aspects suivants : Le rôle des experts et de l’expertise (Sanchez-

A Lejeune UML DIC 9250 – A2009 Page 21

Manzanares, 2008), le fait que processus de design organisationnel soit dans les faits un
processus continu et non de type one shot (idem). Nous avons également mis de côté
la collaboration dans le design (Koivunen, 2007) et la définition tant des intentions
pédagogiques que des situations d’apprentissage entre experts et non experts.

Nous avons pu cependant établir une première base de modélisation UML qui
permettra dans des délais raisonnables d’incorporer les aspects manquants.

Références utilisées

 Brijnjolfson et Schrage (2009). The New, Faster Face of Innovation, sur le Web
http://sloanreview.mit.edu/business-insight/articles/2009/3/5139/the-new-
faster-face-of-innovation/
 Davenport, T. (2009). How to Design Smart Business Experiments, Harvard
Business Review, February.
 Drucker, P. (1994). The Theory of the Business, Harvard Business Review,
September-October.
 Koivunen, N. (2007). Collective expertise: Ways of organizing expert work in
collective settings, Journal of Management & Organization 15: 258-276.
 Morabito, J. Sack, I. Et A. Bathe, (1999). Organization Modelling, Prentice-Hall.
 Sanchez-Manzanares, M. Rico, R. et Francisco Gil (2008). Designing
Organizations : Does Expertise Matter ?, Journal of Business Psychology 23: 87-
101.
 Tchounikine, P. (2009). Précis de recherche en Ingénierie des EIAH, Juin. Sur le
Web.

i
voir
http://www.k8accesscenter.org/training_resources/CRA_Instructional_Approach.asp

A Lejeune UML DIC 9250 – A2009 Page 22