Une approche de la capitalisation des connaissances : lanalyse

des processus de prise de dcision collective

Lewkowicz Myriam1
Zacklad Manuel2
1

LAMSADE
Universit de Technologie de Troyes, laboratoire Tech-CICO
Universit Paris Dauphine
Place du Marchal de Lattre de Tassigny
75775 Paris Cedex 16
lewkowic@lamsade.dauphine.fr
manuel.zacklad@univ-troyes.fr

Rsum:
Le besoin de mmoriser les connaissances tacites dans l'entreprise a t mis en vidence et
tudi en gestion, dans le cadre de l'apprentissage organisationnel. Or beaucoup de ces
connaissances sont changes et cres lors des runions de conception collective. Nous nous
intressons donc aux formalismes reprsentant les argumentations conduisant aux dcisions
lors de ces runions, savoir des formalismes de Design Rationale, en particulier QOC. Nous
identifions des situations de conception que nous qualifions de complexes dans lesquelles il
est impossible d'utiliser QOC. Nous proposons alors un nouveau formalisme, ABRICo, qui
reprsente de faon dynamique la construction pas pas d'une solution complexe, ainsi que
les rles des acteurs prsents lors des runions. Nous mettons enfin en vidence l'efficacit de
cette notation pour m moriser les processus de conception collective dans des situations
complexes dans le cadre d'un projet de mise en place d'un systme de Gestion Electronique de
Documents.
Mots Clef:
Conception cooprative, Design Rationale, Gestion des connaissances, rationalisation,
mmoire collective
Abstract:
Management researchers in Organizational learning have highlighted and studied the need for
the firm to memorize tacit knowledge. A lot of this tacit knowledge is exchanged and created
during collective design meetings. Though we are interested in tools that permit us to
formalize the argumentations that lead to a decision during design meetings, namely Design
Rationale tools, and particularly QOC. We have identified design situations that we have
called complex for which it was impossible to use QOC. That failure lead us to elaborate a
new formalism, ABRICo, that represents dynamically the step by step elaboration of a
complex solution, and the roles of the actors present at the meetings.We successfully test this
formalism in the scope of the set up of a Document Management System.

1. Introduction
On pourrait schmatiquement organiser les pratiques et les recherches sur les outils de
capitalisation des connaissances en trois grandes classes. Certains travaux, notamment
dorigine industrielle, se focalisent sur la dimension documentaire et en adoptant une
approche bottom up , partent de corpus linguistiques pour rechercher partir dune analyse
terminologique puis smantique les concepts importants du domaine ( cf. (Pomian 1996) de la
socit Nemsia). Cette approche permet, par exemple, de concevoir des index et des
thsaurus pour archiver les documents de manire oprationnelle. La seconde sappuie sur
une modlisation systmique sophistique des processus qui sont lobjet de lactivit des
acteurs. Cest le cas de la mthode MKSM dveloppe par J.L Ermine au CEA (Ermine et al.
1996), (Ermine 1996). La troisime approche, dans laquelle sinscrivent nos travaux consiste
prvoir des systmes de recueil structur de lactivit de rsolution de problme et de prise
de dcision qui, dans le contexte des organisations, est presque toujours collective.
Cette approche, prolongement de travaux empiriques du CSCW relatifs notamment au
courant du Design Rationale, est justifie sur le plan thorique par les recherches en gestion
dans le domaine de lapprentissage organisationnel (Koenig 1994). En effet, ces tudes
montrent que la comptence dune entreprise repose sur des savoir-faire collectifs souvent
peu formaliss. Elles mettent en relief le besoin de convertir ces connaissances tacites, de les
expliciter (Nonaka 1994), (Hatchuel 1994), (Reix 1995).
Dans lapproche que nous suivons, nous nous focalisons sur les situations de conception
collective, constitues dinteractions synchrones (des runions) et asynchrone (le travail
mdiatis par ordinateur). Nous pensons en effet quelles constituent un lieu privilgi pour
commencer capturer ces connaissances tacites.
Le Design Rationale qui s'est pos la question de la formalisation des argumentations
conduisant aux prises de dcision collectives en conception (Moran, Carroll 1996) s'est
surtout intress des situations de conception simples (Grudin 1996), dans le sens o la
forme des solutions trouver tait connue, et peu complexe 1 . D'o la ncessit de nouveaux
travaux pour prendre en compte des situations complexes dans lesquelles l'incertitude quant
la forme de la solution construire est grande. Afin d'tre ralistes et comprhensibles, ces
nouveaux formalisme s devront reprsenter l'volution dynamique d'une solution, et les rles
des acteurs participant la prise de dcision.
Nous commencerons par prsenter la manire dont les gestionnaires tudient les
connaissances tacites dans l'apprentissage organisationnel, puis nous dcrirons ce qu'est le
Design Rationale et plus particulirement un de ses formalismes (QOC). Nous dfinirons
ensuite ce que nous appelons situations complexes de conception. Nous proposerons enfin, en
nous appuyant sur des exemples concrets, un formalisme de rationalisation des processus de
prise de dcision dans ces situations de conception complexes. Nous conclurons en proposant
des axes de recherche futurs pour complter cette approche.

2. La problmatique de l'apprentissage organisationnel

Le concept d'apprentissage organisationnel (Simon 1963), (Cyert, March 1963), (March,
Olsen 1975) provient du constat selon lequel l'amlioration des capacits de l'organisation ne
rsulte pas seulement de l'amlioration des capacits des individus. Il devient le thme central
d'une importante contribution la recherche en gestion avec le livre d'Argyris et Schn
(Argyris, Schn 1978). Dans ces travaux, les auteurs distinguent les theories in use qui
1

Nous insistons sur le fait que nous parlons de la complexit de la solution et non de la complexit du processus
de rsolution.

gouvernent rellement l'action et les espoused theories qui peuvent se lire dans les
documents formels. L'apprentissage dbute lorsque des rsultats sont en dsaccord avec les
attentes issues de la theory in use. Dans des travaux rcents (Nonaka 1994), (Le Moigne,
Bartolli 1996), (Reix 1995), on retrouve la mme distinction entre deux formes de
connaissances : tacites qui sont difficiles formaliser (qui relvent par exemple des savoirfaire) et des explicites qui sont codifiables, formalisables. Pour Nonaka (Nonaka 1994),
l'apprentissage organisationnel repose sur des conversions entre ces deux formes de
connaissances. Enfin, pour Argyris et Schn (Argyris, Schn 1978), comme pour Levitt et
March (Levitt, March 1988) et Nonaka (Nonaka 1994), il n'y a vraiment apprentissage que si
les rsultats sont inscrits dans la mmoire de l'organisation et pas seulement dans la mmoire
de l'individu.
Pour ces deux types de connaissances, il serait souhaitable que les projets disposent de
systmes daide la capitalisation. Les outils de Gestion Electronique de Documents (GED),
largement utiliss notamment dans le contexte des processus de certification qualit,
rpondent au besoin de mmorisation des connaissances explicites. En revanche, le problme
subsiste pour la reprsentation des connaissances tacites, reprsentation qui ne sera bien sr
possible qu lissue dun processus dexplicitation progressif.
Si, dans le cadre de lapprentissage organisationnel, les connaissances tacites efficaces
possdent un caractre collectif, on peut lgitimement penser que les runions et les
discussions constituent des temps privilgis o elles se manifesteront et commenceront
sexpliciter. Ceci pourrait expliquer lefficacit des mthodes de Design Rationale qui, par le
formalisme quelles suggrent, catalysent lexplicitation des connaissances changes entre
les concepteurs. C'est donc ce domaine que nous allons maintenant prsenter.

3. Qu'est-ce que le Design Rationale ?

3.1. En gnral
Le but des recherches en Design Rationale (DR) est de dvelopper des mthodes et des
reprsentations assistes par ordinateur pour obtenir, maintenir et rutiliser les raisons pour
lesquelles des dcisions de conception ont t prises. Lobjectif est de mmoriser les
raisonnements de faon la plus raliste et la moins coteuse possible mais de faon assez
structure et claire (Mac Lean, Young, Moran 1989). Ainsi, ce qui a t mmoris pourra tre
compris et utilis par une personne extrieure tentant de comprendre l'objet conu. Etant
donn que l'activit centrale des runions est la formulation et la critique d'arguments, le
projet du Design Rationale est de dvelopper des reprsentations schmatiques qui permettent
d'assister par ordinateur la cration, l'valuation et la modification d'arguments. L'hypothse
principale est qu'en rendant la structure des arguments explicite, ils seront construits et
expliqus de faon plus rigoureuse. Il existe diffrentes mthodes qui ont t dveloppes. La
diffrence entre ces mthodes rside dans le formalisme choisi pour reprsenter les
arguments, ce qui dtermine le type d'arguments qui seront mmoriss et le niveau de dtail
qui pourra tre obtenu. Nous pouvons citer DRL (Design Representation Language) (Lee, Lai
1996), IBIS (Issue-Based Information Systems) (Yakemovic, Conklin 1993), QOC
(Questions, Options and Criteria) (Mac Lean, Young, Bellotti, Moran 1996). Cest cette
dernire mthode, dveloppe l'EuroPARC de Rank Xerox (Cambridge), qui permet de
reprsenter diffrentes solutions avec leurs avantages et leurs inconvnients dans un espace
de conception graphique, que nous allons maintenant dcrire.

3.2. L'exemple de QOC

La mthode QOC aide la reprsentation de processus de dcisions de conception sous la
forme de schmas composs d'une Question qui correspond une situation problme,
d'Options qui sont des solutions envisageables et de Critres qui permettent de choisir entre
ces Options. Une Option peut amener se poser une Question supplmentaire. Un lien en trait
plein entre une Option et un Critre signifie que le critre est favorable l'option, sinon, il est
dfavorable. La forme gnrale d'un schma QOC est la suivante :

Critre
Option

Peut-tre-rsolue-par

Question
Option

Critre

est-favorable-

Critre

est-dfavorable-

Question

entrane

Figure 1: Forme gnrale d'un schma QOC

Les exprimentations de la mthode QOC ont en gnral t concluantes (Karsenty
1996), (Schum 1996), (Schum et al. 1996). Certaines difficults ont toutefois t identifies
dans certains cas (Schum 1996), (Lewis, Riemann, Bell 1996). Ces difficults concernent
lidentification du niveau de gnralit des Questions, la formulation des Options ou
l'expression des Critres.
Finalement, quand il est possible de proposer diffrentes alternatives, quand le temps
d'laboration des solutions est court, et que le rle des acteurs des runions n'est pas un
lment prendre en compte, les formalismes classiques de Design Rationale comme QOC
sont utilisables et sont une reprsentation utile d'une prise de dcision classique comme un
choix ou un tri2 .
Mais lorsque la solution se construit petit petit et o on ne peut pas en comparer
plusieurs simultanment, on ne peut pas utiliser les formalismes existant du Design Rationale.
Nous allons maintena nt identifier en quoi consistent ces situations que nous avons nommes
complexes et proposer une faon de formaliser les discussions conduisant aux prises de
dcision dans ces cas-l.

4. Que sont les situations complexes de conception ?

Nous caractrisons les situations de conception collective complexes comme suit :
4.1. Incertitude
Comme le fait remarquer Hoc (Hoc 1987), les stratgies de rsolution de problmes sont
diffrentes suivant le niveau de connaissances possd sur le sujet, et le niveau de dtail de
ces connaissances. Dans des projets de conception de grande ampleur, les concepteurs font
face une grande incertitude quant la forme de la solution qu'ils adopteront. Le niveau de
2

Dautant plus que, comme le fait remarquer Hoc (Hoc 1987), ces situations o on explore simultanment
plusieurs solutions (recherche en largeur dabord), sont trs coteuses en mmoire de travail.

connaissances est faible au dbut du projet. Pour rduire cette incertitude, les concepteurs
adoptent des stratgies en profondeur d'abord, qui les amnent descendre dans le dtail
d'une solution, quitte la remettre entirement en cause, contrairement une conception en
largeur d'abord, o on examine plusieurs solutions parmi lesquelles on doit faire un choix.
Ce qu'il est ncessaire de reprsenter dans des situations complexes, c'est l'volution d'une
solution au cours du projet grce au niveau de connaissances qui augmente, et non le tri ou le
choix entre plusieurs solutions dont on connat la forme (Giard, Midler 1996) 3 .
4.2. Temps
Comme nous l'avons soulign en introduction, les situations de conception complexes
s'inscrivent dans des priodes de temps assez longues. Pour rationaliser le processus, il est
donc ncessaire de restituer les volutions progressives de l'bauche en datant les diffrentes
versions pour en restituer la phylogense. Dans certains cas, les nouvelles propositions
suivent des chemins directement opposs aux prcdents. Dans d'autres, au contraire, elles
combinent diffrentes caractristiques des propositions antrieures. Parce que les formalismes
classiques du DR privilgient la mise en vidence des relations logiques entre les noncs, ils
projettent les lments de discussion sur un espace atemporel. Ce faisant, ils ne permettent
pas de saisir la dynamique du processus. En introduisant cette dimension, nous esprons
fournir une meilleure comprhension de l'volution de la solution4 qui amliorera encore les
possibilits de rvision aprs-coup de la solution. Ainsi, si certaines contraintes du projet sont
modifies, il sera possible d'identifier quel(s) moment(s) ces contraintes avaient pes sur la
conception, et on pourra envisager l'laboration d'une nouvelle solution en partant de ce point,
sans avoir rexaminer des lments de dcisions antrieures.
4.3. Rles
Le but du Design Rationale est de reprsenter des argumentations qui conduisent des
prises de dcision dans des situations de conception. Or dans de telles situations, les acteurs
peuvent tenir des rles trs varis. Par exemple, lors dune runion de projet : reprsentants de
la matrise douvrage qui finance le projet, reprsentants de la matrise duvre qui ralise le
projet, parmi ceux- l, on peut avoir un chef de projet, des concepteurs, un responsable qualit,
etc. Cette diversit a une influence sur le droulement des processus de conception. Le fait
didentifier le rle de lacteur qui formule un argument permet une meilleure comprhension
de la discussion parce qu'il permet de mettre jour un critre non formul dans la runion. Ce
critre tient linfluence de la source qui formule une opinion. En effet, un argument n'aura
pas le mme poids, voire la mme signification, selon qu'il aura t formul par le chef de
projet, le responsable qualit ou un concepteur par exemple. Les formalismes classiques de
Design Rationale, ne peuvent pas rendre compte dun des lments important des situations
complexes de conception quest la diversit des rles parce que ces derniers napparaissent
pas dans les formalismes. Ce sera donc un lment prendre en compte pour une
rationalisation des processus de prise de dcisions dans des situations de conception
collective complexes.
3

On pourrait dire que ce qui diffrencie un processus de production dun processus projet, cest que lissue du
premier est anticipe au dpart, alors quil faut sengager dans le second pour savoir sil ira jusqu son terme, et
o ce terme se situera exactement. Insistons ici sur le fait que lincertitude porte aussi sur lobjectif vis.
Affirmer lexistence a priori dune cible ne signifie pas que celle-ci puisse tre prcisment dfinie et de manire
sre au dpart. , (Midler 1996)
4
voir ce propos le diagramme de lvolution de la connaissance et des degrs de libert dun projet en fonction
du temps dans (Giard, Midler 1996)

5. Comment tenir compte de la complexit, du temps et des rles ?

5.1. Un exemple de situation de conception complexe
Nous avons assist des runions runissant les principaux participants d'un march
s'inscrivant dans le cadre d'un projet du centre de Recherche et Dveloppement de FRANCE
TELECOM sur la qualit des logiciels. Le but de ce march tait la mise en place d'une
solution de gestion et de production de document et le suivi de cette exprimentation sur un
site pilote. La solution, base sur un logiciel de gestion lectronique de documents (GED),
devait en particulier faciliter le travail coopratif sur un mme fonds documentaire. Le contrat
tait compos de quatre phases. Celle que nous avons tudie est la premire, d'une dure de
trois mois, consistant en une analyse des besoins et un maquettage. A la fin de cette phase, le
comit de projet FRANCE TELECOM devait dcider sil acceptait les propositions et l'outil
de l'entreprise choisie.
Des dcisions importantes quant aux rsultats finaux taient prises dans les runions 5 ,
mais sans que ce soit le but affich. Les discussions taient plus des changes de points de
vue sur la solution apporte et ne comportaient pas rellement d'Options pour rpondre une
Question et de Critres pour choisir ces Options. Pour chacune des runions auxquelles nous
avons assist, nous avons cherch appliquer la mthode QOC mais sans aucun succs.
5.2. Une rponse : ABRICo
Lorsque nous analysons les runions dcrites ci-dessus, nous pouvons faire des
constatations quant la structure et au contenu. Ces runions consistent en des prsentations
de l'avancement du travail du point de vue du fournisseur et en un contrle et/ou une
validation du point de vue du client. Les dcisions qui sont prises sont plus le rsultat
d'interactions entre diffrents acteurs au cours d'une ou plusieurs runio ns que la rsultante
d'un tri ou d'un choix d'une solution propose suite une recherche initie par une demande
prcise. Dans les runions auxquelles nous avons assist, nous avons un but atteindre,
chaque partie prenante interprtant ce but, identifiant des fonctions mettre en uvre pour
l'atteindre et cherchant comment mettre en uvre ces fonctions. Nous allons maintenant
dfinir ces concepts et construire les modles qui dcriront les processus de prise de dcision
partir de ces concepts.
5.2.1. Le formalisme
But commun : le but exprime un besoin satisfaire. Il peut tre identifi grce une partie du
contrat, dans ce cas il est assimil un objectif atteindre par une partie prenante. Le but peut
aussi rsulter d'un accord entre les parties prenantes, par exemple l'utilisation d'une mthode
particulire pour rsoudre un problme. C'est un lment commun aux parties prenantes, c'est
le point de dpart d'un processus de travail dans lequel on va trouver les catgories qui
suivent. Par exemple, un but peut tre concevoir une modlisation qui puisse servir de
mthodologie.

Les acteurs des runions n'taient pas toujours el s mmes mais faisaient toujours partie des personnes
suivantes: Pour FRANCE TELECOM, le responsable technique, l'expert GED (Gestion Electronique de
Documents), l'expert processus et mthodes et le reprsentant des utilisateurs. Pour la socit prestataire, que
nous nommerons ici VERSAN, le directeur du projet, le chef du projet (consultant senior), son assistant
(consultant junior), l'expert GED, et le spcialiste informatique.

Interprtation d'Une Partie Prenante (upp) : l'interprtation exprime la faon dont un acteur
ou un groupe d'acteurs s'approprie le but et rflchit la faon de le rsoudre. C'est une
fonction mettre en uvre pour atteindre le but. Chaque partie prenante a sa propre
interprtation du but et c'est ce qui entranera les discussions. Par exemple, une interprtation
peut tre analyser les processus de travail.
Proposition d'Une Partie Prenante (upp) : cest une proposition de mise en uvre de
l'interprtation. Cette interprtation peut tre celle de la partie prenante qui met la
proposition ou celle d'une autre partie prenante. La proposition est alors une raction sous
l'effet d'une sollicitation de la part de l'autre partie prenante. La proposition consiste montrer
comment il est possible de raliser les fonctions qui permettent d'atteindre le but. Par
exemple, une proposition peut tre une prsentation de schmas.
Accord Des Parties Prenantes (dpp) : l'accord survient lorsqu'il y a consensus sur la(les)
proposition(s) mise(s) face l'interprtation. C'est donc un lment commun toutes les
parties prenantes, qui peut intervenir au cours du processus de travail et qui reprsente une
dcision lorsque c'est la clture du processus. Par exemple, un accord peut tre l'acceptation
de certains schmas ou la dcision d'utiliser un outil en particulier.
A partir des catgories d'analyse prsentes ci-dessus, nous avons construit un modle
statique qui identifie les types de lien qui existent entre les catgories et un modle
dynamique qui montre comment elles peuvent senchaner au cours d'une ou de plusieurs
runions. Nous avons baptis cette modlisation ABRICo pour Accord, But, pRoposition,
Interprtation en Conception.
Dans le modle statique, nous montrons quelles sont les relations qui existent entre les
catgories d'analyse, donc entre but, interprtation et proposition mais aussi les relations qui
peuvent exister entre deux interprtations ou entre deux propositions. Ce modle nous permet
de complter les dfinitions des concepts fournies plus haut (voir figure 2). Le fait
d'instancier ce modle sur un processus de prise de dcision permettra une meilleure
comprhension de la structure de ce dernier.

est-oprationnalis-par
But commun

est-concrtise-par
Interprtation upp

permet-un
pRoposition upp

Accord dpp

sucite-une

prcise
Interprtation u p p

complte
Interprtation upp

est-oppose-

pRoposition upp

pRoposition upp
est-oppose-

Figure 2- modle statique ABRICo

Nous allons illustrer cette reprsentation statique par un exemple issu de la vie
courante pour une question de clart : il s'agit de deux couples d'amis qui dcident de passer
une semaine de vacances ensemble et doivent choisir leur destination. (voir figure 3).

But

Interprtation
Se reposer

pRoposition

Accord
Est-oprationnalis-par une
Interprtation

La Martinique

Est-concrtise-par une
pRoposition
Passer une
semaine de
vacances en
dehors de la
France
Mtropolitaine

Endroit o on
peut marcher

Se dpenser

Est-oppose-
Permet un Accord

La Runion

Suscite une Interprtation

Complte, Prcise

Doit tre
culturel

Endroit avec
des monuments

Turquie

Couple 1
Couples 1et 2

Couple 2

Rserver
pour la
Turquie

Figure 3- Exemple de reprsentation statique d'un processus de co-conception

Le modle dynamique reprsente la faon dont les catgories d'analyse sont lies dans
le temps. Le processus de prise de dcision commence par la dfinition d'un but commun,
suivie de l'interprtation d'une partie prenante et de sa proposition, proposition entranant
l'interprtation d'une autre partie prenante. Afin d'illustrer ce modle, nous allons donner le
mme exemple que prcdemment, avec une reprsentation dynamique (voir figure 4).
Couples 1 et 2

Couple 1

Couple 2
Est-suivi-de

Passer une semaine

de vacances en
dehors de la France
mtropolitaine

Se reposer
But
Interprtation
La Martinique

Se dpenser

Proposition
Accord

La Runion

Endroit o on
marche

Doit tre aussi

culturel

Rserver pour la
Turquie

Turquie

Endroit avec des

monuments

Symtrique

Figure 4- Exemple de reprsentation dynamique d'un processus de co-conception

5.2.2. Instanciation des modles sur un exemple
Nous allons illustrer ces modles grce un exemple de processus de prise de dcision
lors de runions de travail en groupe dont le but tait fix par un contrat, savoir
llaboration dune dmarche danalyse des besoins pour la production et larchivage
documentaires. Nous instancierons d'abord le modle dynamique (voir figure 5) o nous
prciserons l'ordre de lecture du schma par des chiffres sur les flches, puis le modle
statique (voir figure 6) o nous prciserons les parties prenantes.

C l i e n t e t F o u r n i s s e u r

E l a b o r e r u n e
d m a r c h e d a n a l y s e
d e s b e s o i n s p o u r l a
p r o d u c t i o n e t
l a r c h i v a g e
d o c u m e n t a i r e s

F o u r n i s s e u r

C l i e n t

A n a l y s e r l e s
p r o c e s s u s
d o c u m e n t a i r e s

2
P l a n d a c t i o n p o u r
l a n a l y s e d e s p r o c e s s u s
d o c u m e n t a i r e s

A n a l y s e r
l e s p r o c e s s u s
d e t r a v a i l

4
P r
e n
p r o
d o
c e r t a i n s p r o c e s s u s
s o n t b i e n m o d l i s s

P r s e n t a t i o n
f o r m a l i s a t i o n d e
( s c h m a s ) , c e n t r
d o c u m e n

d ' u n e
l a c t i v i t
e s u r l e s
t s

o p o s i t i o n d e p l a n d a c t i o n
t r o i s p a r t i e s : a n a l y s e d e s
c e s s u s d e t r a v a i l , f o n c t i o n s
c u m e n t a i r e s e t c o u v e r t u r e
f o n c t i o n n e l l e

8
9

L e s p r o c e s s u s
d e t r a v a i l
s o n t b i e n m o d l i s s

P r s e n t a t i o n d u n e
f o r m a l i s a t i o n d e
l a c t i v i t l a r g i e d e s
a s p e c t s n o n
d o c u m e n t a i r e s

L a n a l y s e d e s
p r o c e s s u s n e
d o i t p a s t r e
c e n t r e s u r l e s
d o c u m e n t s

1 0
d e

N c e s s i t
d ' a v o i r u n e
m t h o d e
m o d l i s a t i o n

1 1
U t i l i s e r l a m t h o d e
et l'outil A R I S

1 2
U t i l i s a t i o n
d ' A R I S p o u r
l a m o d l i s a t i o n

1 3
L o c a t i o n d ' A R I S
B u t

c o m m u n

A c c o r d
I n t e r p r t a t i o n
p R o p o s i t i o n

Figure 5- Modle dynamique d'un processus de co-conception

But

Interprtation

pRoposition

fournisseur
Analyser les
processus
documentaires

Accord

fournisseur
Plan d'action pour
l'analyse des
processus
documentaires

client
client
client, fournisseur

Analyser les
processus de travail

Elaborer une dmarche

d'analyse des besoins
pour la production et
l'archivage documentaires

client
L'analyse des
processus ne doit
pas tre centre
sur le document

client
Ncessit d'avoir une
mthode de
modlisation (pour
construire les
schmas)

Est-oprationnalis-par une
Interprtation
Permet un Accord

Est-oppose-

Proposition de plan d'action

en trois parties: analyse
des processus de travail,
fonctions documentaires et
couverture fonctionnelle

fournisseur
Prsentation d'une
formalisation de
l'activit (schmas)
centre sur les
documents

client, fournisseur
Certains processus
sont bien modliss

fournisseur
Prsentation d'une
formalisation de
l'activit largie des
aspects non
documentaires

client, fournisseur
Les processus de
travail sont bien
modliss

client
Utiliser la
mthode et
l'outil ARIS

Est-concrtise-par une pRoposition

Complte, Prcise

fournisseur
Location d'ARIS

Figure 6- Modle statique d'un processus de co-conception

client, fournisseur
Utilisation d'ARIS
pour la modlisation

6. Conclusion
Aprs avoir rappel comment les gestionnaires, dans le cadre de l'apprentissage
organisationnel, dfinissent les connaissances qui interviennent dans les processus collectifs,
nous avons montr qu'il tait ncessaire de trouver des reprsentations pour expliciter les
connaissances tacites. Notre hypothse de travail consistant dire que les runions et les
discussions constituent des temps privilgis o ces connaissances se manifestent et
commencent s'expliciter, nous nous sommes naturellement intresss au domaine du Design
Rationale.
Aprs avoir expriment QOC, un de ses formalismes, nous avons conclu que les
mthodes classiques du Design Rationale ne sont pas adaptes toutes les situations. Quand
la complexit de la solution trouver est faible et que le niveau de connaissances sur la
solution concevoir est lev, les techniques classiques du Design Rationale, et plus
prcisment la mthode QOC qui est claire et facilement appropriable sont adaptes. Par
contre, pour des situations complexes dans lesquelles on fait une recherche en profondeur
dabord et o il est ncessaire de prendre en compte le dynamisme du processus et les rles
des acteurs impliqus dans ce processus, les mthodes classiques du Design Rationale ne sont
plus suffisantes.
Comme nous tions dans l'impossibilit d'utiliser la mthode QOC pour modliser les
processus de conception lors des runions du projet de France Tlcom, nous avons cherch
tendre le domaine du Design Rationale ces situations de conception complexes. Pour cela,
nous avons dvelopp le formalisme ABRICo que nous avons utilis avec succs dans le
cadre de ce projet de mise en place dune solution de Gestion Electronique de Documents
France Tlcom. Ce formalisme reprsente l'volution d'une solution au cours des runions et
tient compte des rles des acteurs de ces runions
Notre objectif est maintenant denrichir et de dvelopper ce formalisme. Nous avons pour
cela intgr rcemment une quipe projet du Systme dInformation de France Tlcom. Au
vu de l'organisation de ce projet, nous pouvons dj remarquer que la reprsentation d'une coconception client-fournisseur peut tre affine. Nous avons en fait trois groupes d'acteurs :
d'abord la matrise d'ouvrage qui est, en quelque sorte, un client et qui nonce des Buts.
Ensuite la matrise d'uvre qui identifie des fonctions mettre en uvre pour raliser ces
Buts. Ses contributions sont donc de l'ordre des Interprtations. Enfin, le sous-traitant qui
rflchit la faon de mettre en uvre les fonctions identifies par la matrise d'uvre. Ses
contributions sont donc des pRopositions.
A partir de ce constat, nous pouvons envisager une fonctionnalit supplmentaire
d'ABRICo, qui viendra s'ajouter la rationalisation des processus de conception collective,
savoir l'valuation des apports des diffrents groupes d'acteurs du projet : la matrise
d'ouvrage met-elle bien des Buts, la matrise d'uvre des Interprtations et le sous-traitant
des pRopositions ?
La prise en compte des rles ouvre donc la voie une tude de la dynamique
organisationnelle au sein des groupes projet ; facteur que les sciences de gestion ont mis en
vidence depuis longtemps et qui semble aussi trs structurant dans la construction de la
mmoire collective.

7. Rfrences
ARGYRIS C., SCHN D.A. (1978), Organizational learning: a theory of action perspective,
ADDISON WESLEY.

CYERT R., MARCH J. (1963), A behavioural theory of the firm, PRENTICE HALL,
ENGLEWOODS CLIFFS, New Jersey, USA.
ERMINE, J. L. (1996), Les systmes de connaissances, HERMES .
ERMINE, J. L. , CHAILLOT, M., BIGEON, P., CHARRETON, B., MALAVIEILLE, D. (1996),
MKSM, a method for knowledge management, Proceedings of the 5th Int. Symposium on the
Management of Industrial and Corporate Knowledge (ISMICK'97), Compigne, France, p.
288 - 302.
GIARD V., MIDLER C. (1996), Management et gestion de projet : bilan et perspectives,
http://panoramix.univ-paris1.fr/GREGOR/96-11.html.
GRUDIN J. (1996), Evaluating opportunities for design capture, in T.P. MORAN & J.M.
CARROLL (Eds.), Design Rationale: Concepts, Techniques and use, LAWRENCE ERLBAUM
ASSOCIATES .
HATCHUEL A. (1994), Apprentissage collectif et activits de conception, Revue Franaise de
Gestion, pp 109-120, Juin-Juillet-Aot.
HOC J.M. (1987), Psychologie cognitive de la planification, Presses Universitaires de
Grenoble.
KARSENTY L. (1996), An Empirical Evaluation of Design Rationale Documents, CHI 96, 1318 Avril.
KOENIG G. (1994), L'apprentissage organisationnel :reprage des lieux, Revue Franaise de
Gestion, Janvier-Fevrier 1994, pp. 76-84.
LEE J., LAI K.Y. (1996), What's in Design Rationale, in T.P. MORAN & J.M. CARROLL (Eds.),
Design Rationale: Concepts, Techniques and use, LAWRENCE ERLBAUM ASSOCIATES .
LE MOIGNE J.L., BARTOLLI J.A, Organisation intelligente et Systme d'Information
stratgique, ECONOMICA , 1996.
LEVITT B., MARCH J.G. (1988), Organizational learning, Annual Review of Sociology, 14,
pp. 319-340.
LEWIS C., RIEMAN J., BELL B. (1996), Problem-Centered Design for Expressiveness and
Facility in a Graphical Programming System, in M ORAN TH.P., CARROLL J.M., Design
Rationale Concepts Techniques and Use, LAWRENCE ERLBAUM ASSOCIATES .
MAC LEAN A., YOUNG R.M., MORAN T.P. (1989), Design Rationale : The argument beyond
the artefact, in Proceedings of CHI 89, Austin Texas, April 30-May 4 1989 ACM PRESS.
MAC LEAN A., YOUNG R.M., BELLOTTI V.M.E., MORAN P. (1996), Questions, Options and
Criteria : Elements of Design Space Analysis, in MORAN TH.P., CARROLL J.M., Design
Rationale Concepts Techniques and Use, LAWRENCE ERLBAUM ASSOCIATES .

MARCH J.G., OLSEN J.P. (1975), The uncertainty of the past: organizational learning under
ambiguity, European Journal of Political Research, 3, pp. 147-171.
MIDLER C. (1996), l'auto qui n'existait pas, management des projets et transformation de
l'entreprise, INTEREDITIONS.
MORAN TH.P., CARROLL J.M. (1996), Design Rationale Overview, in MORAN TH.P.,
CARROLL J.M., Design Rationale Concepts Techniques and Use, LAWRENCE ERLBAUM
ASSOCIATES .
MUNIER B. (1994), Dcision et Cognition, Revue Franaise de Gestion, pp 79-92, JuinJuillet-Aot.
NONAKA I. (1994), A dynamic theory of organizational knowledge creation, Organization
Science/ Vol. 5, N1, pp 14-37, February.
POMIAN J. (1996), Mmoire d'entreprise, Les Editions SAPIENTIA , 1996.
REIX, R. (1995), savoir tacite et savoir formalis dans lentreprise, Revue Franaise de
Gestion n105, pp 17-28, septembre-octobre.
SIMON H.A. (1963), Birth of an organization, the economic cooperation administration,
Public Administration Review, 13, pp. 227-236.
SCHUM S.B. (1996), Analysing the Usability of a Design Rationale Notation, in MORAN
TH.P., CARROLL J.M., Design Rationale Concepts Techniques and Use, LAWRENCE
ERLBAUM ASSOCIATES .
SCHUM S.B. et al. (1996), Graphical Argumentation and Design Cognition, Technical Report
KMI-TR-25, Knowledge Media Institute, The Open University, U.K.
YAKEMOVIC K.C.B., CONKLIN E.J. (1993), Report on development project use of an IssueBased Information System, in Readings in Groupware and CSCW, pp 566-579, MORGAN
KAUFMANNN PUBLISHERS.