Préambule

L’activité de conception

La conception est généralement reconnue comme une activité complexe et créative requérant des

connaissances provenant de multiples domaines et leur synthèse. Deux situations de conception sont

classiquement distinguées (Brown, 1996) (cité dans (Blanco, 1998)) :

• La conception routinière, consistant à concevoir un artefact dans un cadre relativement bien

défini et dont l'élaboration de la solution, si celle-ci n'est pas forcément triviale, laisse peu

de place aux incertitudes (i.e. concevoir une chaîne de traitement de documents

convertissant des pages Internet en fichiers textes). L'existence d'une solution ne fait pas de

doutes et les termes dans lesquels celle-ci sera réalisée ainsi que les moyens d'y parvenir

sont assez clairement établis dès le début.

• Les situations de conception créatives, qui, à l'inverse, font face à des problèmes dont la

définition est floue, pour lesquels l'existence d'une solution et les façons d'y parvenir ne

sont pas clairement établis à l'avance, et une part conséquente du processus de conception

est consacrée à rechercher et à préciser les termes de la solution et les moyens d'y parvenir

(i.e. concevoir un procédé permettant de reproduire la teinte d'un alliage, marque de

fabrique d'une entreprise, sur une nouvelle chaîne de production, alors que cette teinte

était un effet de bord des anciens moyens de production plus artisanaux (Schön, 1983)).

Ces deux situations modèles sont d’avantage les deux extrêmes d'un continuum qu'une stricte ligne

de partage sur l'activité de conception, la plupart des projets de conception ont en effet leurs parts

d'incertitudes sur la définition des problèmes, les solutions qu'ils visent ou les moyens d'y parvenir.

Comme le soulignent les travaux de (Simon, 1996) dès lors que les concepteurs font face à des

situations réelles où tout ne peut être définit et maîtrisé, l'enjeu est moins de concevoir une solution

55

optimale qu'une solution satisfaisante eu égard aux multiples contraintes que doit intégrer un projet

réel (temps, moyens, environnement, utilisateurs). A ce titre, la définition du problème ou des

problèmes posés pour le projet de conception est déjà une façon de traiter cette complexité. Deux

approches se distinguent sur ce point.

• Une approche de « résolution de problèmes » (Simon, 1996) proposant de réduire la

situation de conception en définissant un cadre - le problème - constitué de catégories et de

connaissances qui limiteront le champ de recherche des moyens pour parvenir à une

solution. Des opérateurs permettant de résoudre le problème sur la base des connaissances

le définissant sont recherchés en vue d'élaborer une solution satisfaisante la plus proche de

l'optimal. Des outils plus ou moins formels (Cross, 2000) ont été élaborés en vue d'aider le

concepteur à définir son problème (i.e. la méthode des arbres d'objectifs, « the objectives

tree method » (Cross, 2000)), par exemple en l'aidant à réduire la situation en problèmes

plus élémentaires, et en le guidant dans le choix de solutions qui le rapprocheront de la

résolution du problème, définit en termes de satisfaction d'objectifs quantitatifs ou

qualitatifs. La définition du problème est un moment crucial dans ce type d'approche car elle

exerce une contrainte forte sur les moyens à mettre en place pour résoudre le problème et

les termes de la solution.

• Une autre approche, que nous qualifierons de « construction de problèmes », considère

l'élaboration du problème comme faisant partie du travail même de conception et non d'une

analyse préalable, le problème n'est plus posé a priori mais construit et négocié dans la

recherche de la solution puisqu'il participe à la définir. La recherche d'une solution devient

également la recherche de problèmes dans un dialogue avec la situation (Schön, 1983). Les

actions entreprises dans le cadre de la démarche de conception participent à explorer le

problème, à le construire et ainsi à contraindre les choix d'actions à venir. Ce cheminement

ne prétend pas épuiser la situation mais permet, dans un aller-retour systématique entre

proposition de solution et attention aux effets sur le terrain, d'élaborer progressivement une

proposition satisfaisante portant à la fois sur la définition du problème et sur la pertinence

de la solution proposée à cet égard. Cette approche propose d'explorer la complexité plutôt

que de la réduire, elle ne présuppose pas l'existence d'une solution optimale mais plutôt,

dans l'idée de marge organisationnelle (« organizational margin » (Markus Rohde, 2007)

(Hartmann & M. Rohde, 1993)), que plusieurs directions peuvent être prises avec chacune

des conséquences différentes. Les concepteurs en tant que participants à la situation ont

ainsi également des effets sur son évolution qui doivent être pris en considération.

La conception de dispositifs de support aux activités coopératives et d'interaction homme machine

qui nous intéresse pose une limite aux possibilités de définition du problème de conception. La

conception est dans ce cadre un travail avec l'humain, et les concepteurs ne sont pas les seuls à

définir le problème (Wulf & Markus Rohde, 1995) (Carroll, 2000); les utilisateurs et leur activité, y

prennent une part conséquente sinon majeure. Plusieurs façons d'aborder cette responsabilité

partagée de la définition du problème de conception existent comme nous le verrons au travers des

différentes démarches de conception présentées dans ce chapitre (4.2). Certaines démarches

cherchent à capturer les besoins des utilisateurs en définissant et négociant des listes de

fonctionnalités et de pré-requis à partir de différentes sources de connaissances (expertise,

56

entretiens, ethnographie), d'autres approches s'appuient sur la participation active des utilisateurs

dans la définition des problèmes et solutions pour concevoir le dispositif et son utilisation.

Par ailleurs, les situations de conception de dispositifs de supports aux activités coopératives sont

reconnues comme complexes, notamment parce que ces dispositifs s'adressent à plusieurs

utilisateurs, ayant souvent des activités, des fonctions et des objectifs différents. Le contexte

organisationnel n'est donc également pas neutre et les utilisateurs finaux ne sont pas toujours les

seuls acteurs concernés par le projet (Oiry, Pascal, & Tchobanian, 2008). Fitzpatrick (G. Fitzpatrick,

1998) décrit le champ du CSCW comme étant confronté à des « wicked problems » (Rittel & Webber,

1973), des problèmes « mal-formés » qui résistent aux tentatives de définition et de caractérisation a

priori, où les multiples objectifs des parties prenantes créent des situations singulières où plusieurs

solutions sont toujours possibles avec des conséquences différentes qui ouvriront d'autres

problèmes.

Ces difficultés ne doivent pas être vues pour autant comme insurmontables, et des démarches

rigoureuses et systématiques, qui caractérisent la recherche en ingénierie (Charlet, 2005), ont été

élaborées en vue de guider les concepteurs dans ces situations, de développer et de mobiliser des

connaissances sur les complexités des mondes sociaux qu'ouvrent chaque projet.

Le processus de conception

Après avoir souligné les complexités inhérentes à l'activité de conception, on peut toutefois

remarquer, en informatique et dans bien d'autres domaines (architecture (Schön, 1983), conception

de produit (Cross, 2000)), que l'on retrouve des traits communs dans les différentes démarches,

méthodes et descriptions des pratiques. Différentes phases apparaissent de façon récurrente dans

les pratiques de conception. Malgré les différences de granularité propres aux différentes

démarches, il semble possible d'abstraire un ensemble d'étapes communes au processus de

conception informatique. On peut énumérer quelques unes de ces étapes qui habitent le discours

quotidien sur les pratiques de conception informatique : l'analyse, la définition des besoins,

l'implémentation, le déploiement...

Toutefois, les bornes de ces étapes demeurent assez floues (Erickson, 1995) et liées aux contingences

d'un projet. L'ensemble devient d'autant plus complexe que la nécessité de concevoir de façon

itérative s'impose de plus en plus comme une évidence. Les allers et venues d'une étape à l'autre

rendent délicate l'identification stricte de telles étapes, par exemple : implémenter pour évaluer la

faisabilité d'une alternative de conception, modifier un composant d'IHM suite à un retour utilisateur

sans repasser par la discussion des analyses et s’assurer de la cohérence globale des spécifications.

Par ailleurs, les termes mobilisés dans les pratiques ne facilitent pas la tâche tant leur caractère est

général. Par exemple, « implémenter une fonctionnalité » peut pour certains participer de l'analyse

(évaluer sa faisabilité), tandis que d'autres rejetteront cette acception laissant la notion

d'implémentation pour la phase de mise à disposition de l'outil aux utilisateurs. Un autre exemple

serait la distinction parfois ténue entre ce qui relève finalement de l'analyse ou de l'évaluation.

57

Notre propos n'est pas de clarifier une fois pour toutes ces distinctions (ce qui semble peu réalisable

de façon universelle, (Erickson, 1995), (Kroes, 2002)), mais de préciser les différentes phases d'un

processus de conception dans le cadre de notre travail en s'efforçant d'en éliminer les ambiguïtés.

Nous insistons sur le fait que le processus n'est pas la démarche. Nous cherchons dans ce qui suit à

décrire de façon générale le processus de conception informatique et non pas à prescrire les étapes

d'une démarche pour concevoir. Il s'agit pour nous de présenter un ensemble d'espaces

problématiques pour l'activité de conception dont la distinction, communément admise bien que

floue, nous servira à situer les différents travaux qui nous ont intéressés ainsi que notre propre

travail par la suite. A l'inverse, une démarche viendrait prescrire un ensemble d'étapes nécessaires

pour accomplir ce processus de conception.

Nous présentons en détail dans ce qui suit les étapes du processus général de conception que nous

définissons dans le cadre de notre travail (Fig. 1) :

a) Caractérisation de l'activité à assister : il s'agit des analyses et grilles mobilisées pour faire

sens et modéliser l'activité à instrumenter. Elles peuvent s'intéresser à l'activité elle-même

(processus, tâches, connaissances mobilisées), à son contexte (analyse de l'organisation,

enjeux sociétaux, stratégiques) ou encore aux acteurs impliqués (besoin du client,

préférences utilisateurs, modélisation des rôles de chacun). Ces dimensions ne sont pas

mutuellement exclusives et souvent plusieurs analyses sont nécessaires.

b) Définition des services à mettre en œuvre : À l'issue des analyses, on spécifie ce que doit

permettre de faire l'outil. Les spécifications sont plus ou moins précises et proches en regard

de la mise en œuvre informatique. Elles peuvent impliquer, entre autres, des scénarios

d'utilisation, des indicateurs de performances à atteindre, des descriptions des interactions,

les objets manipulés via l'outil.

c) Mise en œuvre informatique : Lors de cette étape, les spécifications sont traduites,

implémentées par les développeurs afin de réaliser concrètement l'outil. Cette étape, loin

d'être triviale, impose de faire se rencontrer utilisation envisagée et contraintes techniques.

Les spécifications, aussi détaillées soient-elles, acquièrent seulement à ce moment là leur

réalité en terme informatique et nécessitent souvent un travail de clarification, de

renégociation et de multiples « microdécisions » sont laissées à la charge des développeurs.

d) Intégration dans les pratiques : Il s'agit de l'installation, du déploiement de l'outil dans le

contexte de l'activité qu'il vise à assister. Les utilisateurs sont plus ou moins accompagnés

dans leur utilisation et dans le meilleur des cas se l'approprient au cours du temps. Les

formations, la communication autour de l'outil et du projet sont des moyens classiques

d'accompagner cette phase.

e) Evaluation : Cette étape vise à évaluer l'outil, à rendre compte de ses usages ou de ses

performances vis à vis de l'activité à supporter. On notera qu'elle prend un caractère

particulier dans le cadre de projet de recherche en vue de mesurer des effets (de façon

quantitative ou qualitative) ou de valider des hypothèses qui ont servi de cadre au

développement de l'outil. La perspective de faire évoluer l'outil sur la base de l'évaluation est

58

souvent présente en vue de l'améliorer, de résoudre des problèmes rencontrés par les

utilisateurs ou de profiter d'opportunités mises en lumières par les usages.

Fig. 1 Le processus général de conception

Ce schéma est volontairement linéaire et simpliste, il ne vise pas à représenter l'ensemble des

parcours possibles d'une phase à une autre. Les problèmes rencontrés durant la mise en œuvre

informatique (c) peuvent bien entendu, dans ce cadre aussi, amener à redéfinir les services proposés

(b) ou encore, l'intégration dans les pratiques (e) peut imposer de revenir sur la caractérisation de

l'activité (a). Ces grandes phases mettent l'accent, à notre sens, sur des moments différents qui se

succèdent lors de tout projet de conception.

Ce processus général de conception servira de grille d'analyse en vue de présenter, dans ce qui suit,

un ensemble de travaux des champs du TCAO et de l'IHM qui ont nourri notre travail de recherche.

On s'intéressera plus particulièrement aux phases qui ont reçues une attention particulière dans

chacune des démarches, mais également à celles que nous qualifions de « boite noire », c'est à dire

non mises en question, comme il en existe dans la plupart des démarches. Bien entendu, l'ampleur

du travail de vouloir traiter en détail toutes les phases du processus de conception est énorme et

nous ne prétendons pas y être parvenus.

Dans le document Aloa : un outil de soutien social en ligne pour les aidants familiaux (Page 69-73)