I. MOTIVATION : INNOVATION ET CONCEPTION

1L’innovation est liée à la compétitivité, elle est un mode fondamental et durable de création de valeur. L’innovation dans une entreprise doit être permanente : c’est même un état d’esprit, tant dans l’innovation de nouveaux produits (innovation dite de rupture) que dans l’amélioration des produits existants (innovation dite incrémentale ou dominant design). L’innovation passe impérativement par la conception ou la re-conception dans le second cas : on ne peut innover sans concevoir. En d’autres termes, la conception fait partie du processus d’innovation.

2Par ailleurs, l’innovation peut et doit se gérer pour en maîtriser les risques, il ne suffit pas d’avoir de bonnes idées : l’innovation est aussi un processus – elle est faite de « 1 % d’inspiration et de 99 % de transpiration » (propos prêtés élégamment à Edison).

3Les bonnes pratiques de l’innovation sont donc :

4— conception innovante – ce qui veut dire conception tournée vers l’innovation – et évaluation permanente dans un processus maîtrisé ;

5— organisation du travail et de l’entreprise tournée vers l’innovation.

6On remarquera que la plupart des méthodes classiques de conception ne s’adaptent pas à la conception innovante car elles partent toutes de « besoins » ou de requis, termes qui n’ont pas de sens dans une innovation de rupture. D’autre part, la conception innovante doit être une conception collective mettant en jeu les acteurs de l’entreprise et les clients (ou utilisateurs).

7Dans cet article, nous allons explorer quelques champs de la conception, et montrer qu’une formalisation de la conception participative peut répondre à ces attentes.

8On notera au préalable qu’il existe des méthodes d’appui de l’innovation comme TRIZ (acronyme russe de la Théorie de résolution des problèmes inventifs), mais qui n’est pas une méthode complète de conception : elle sert plutôt la phase dite de créativité. C’est une approche algorithmique pour résoudre les problèmes techniques et pour conduire de façon rigoureuse le développement d’un système tout au long de son évolution technique en déterminant et en implémentant des innovations. TRIZ part du principe que les problèmes rencontrés durant la conception d’un nouveau produit présentent des analogies et, donc, que des solutions analogues doivent pouvoir s’appliquer. Ce constat vient de l’analyse d’une grande masse de brevets par l’auteur de la théorie (Altshuller, 1973). L’ambition de TRIZ est de favoriser la créativité, ou stimuler la recherche de concepts innovants en proposant aux ingénieurs et aux inventeurs des outils de déblocage de l’inertie mentale. À partir de la créativité propre à chacun, TRIZ oriente le concepteur et le guide à chaque étape de la résolution de problème, en proposant systématiquement des solutions génériques et des outils éprouvés. Cela permet de profiter de l’expérience acquise dans différents domaines d’activité et des principes fondamentaux simples qui en ont été tirés.

II. CONCEPTION VS CONCEPTION PARTICIPATIVE

9Pour fonder notre démarche en conception innovante et rechercher une formalisation qui puisse lui convenir, nous allons examiner dans ce paragraphe quelques aspects de la conception « classique » et de la conception centrée utilisateur puis de la conception participative. Nous considérons tout d’abord un domaine exemplaire en la matière, celui de la conception des logiciels qui a été développé puis formalisé depuis de nombreuses années à l’aide de méthodes comme MERISE (Tardieu et al., 1983, 1985 ; Gabay, 1993), SADT (Structured Analysis and Design Technique) (IGL, 1999), OMT (Rumbaugh et al., 1991) et plus récemment UML.

II . 1. CONCEPTION DES LOGICIELS

10Une méthode d’analyse et de conception a pour objectif de permettre de formaliser les étapes préliminaires du développement d’un système afin de rendre ce développement plus fidèle aux besoins du client. Pour ce faire, on part d’un énoncé informel (le besoin tel qu’il est exprimé par le client, complété par des recherches d’informations auprès des experts du domaine fonctionnel, comme par exemple les futurs utilisateurs d’un logiciel), ainsi que de l’analyse de l’existant éventuel (c’est-à-dire la manière dont les processus à traiter par le système se déroulent actuellement chez le client). La conception d’un logiciel peut être effectuée par un processus de résolution de problème qui, à partir d’une conception initiale, identifie des abstractions de plus en plus raffinées. Le processus se répète jusqu’à ce que l’on soit en mesure de préparer une spécification de la conception de chaque abstraction. À chaque itération de ce processus il faut effectuer les étapes suivantes :

11— étudier et comprendre le problème (analyse et spécifications) : examiner le problème sous différents angles ;

12— identifier les caractéristiques d’au moins une solution possible. Il est souvent utile (et parfois indispensable) d’évaluer plusieurs solutions ;

13— décrire toutes les abstractions utilisées dans la solution. Il est conseillé de créer et de mettre au point une description informelle de la conception, ce qui permet de corriger les erreurs de haut niveau avant de commencer la documentation.

14Malgré l’apparence séquentielle de ce processus, il n’est pas rare d’entamer une nouvelle phase de conception avant la fin de la précédente pour avoir des retours d’information. De plus, ce processus est essentiellement descendant et nécessite d’avoir une bonne connaissance du besoin au départ.

II . 2. CONCEPTION CENTRÉE UTILISATEUR

15La conception centrée utilisateur (CCU) consiste à considérer les utilisateurs et leurs besoins tout au long du processus de développement d’une application informatique. La norme ISO 13407 définit cette pratique.

16Le concept part de l’idée que les utilisateurs finaux sont les mieux placés pour évaluer et influencer le développement d’un produit, car, « si le produit final correspond à leurs besoins, envies et caractéristiques, il aura toutes les chances d’être adopté ». La conception centrée utilisateur impose que le développement du produit soit guidé par les besoins des utilisateurs plutôt que par les possibilités technologiques. La CCU en tant que processus de développement inclut un ensemble de méthodes spécialisées, destinées à recueillir des entrées utilisateur et à les convertir en choix de conception.

17Le concept d’utilisateur final réfère ici à deux types de référents :

18— l’utilisateur final réel, c’est-à-dire qui utilisera l’application de façon personnelle ou professionnelle après son lancement (et éventuellement qui utilise déjà une version précédente du produit) ;

19— l’utilisateur final potentiel, qui présente les mêmes caractéristiques que celles de la cible prévue.

20On doit donc faire intervenir des participants représentatifs d’un type spécifique de cible (en termes d’âge, de culture, d’expérience avec l’outil informatique, d’expertise dans un domaine de connaissance donné, d’environnement technologique, etc.).

21Le processus de CCU ne se contente pas de demander aux utilisateurs ce qu’ils désirent, mais bien de mettre en œuvre des méthodes rigoureuses de recueil de données concernant leurs tâches, besoins, puis leur satisfaction, leur efficacité et leur efficience dans l’utilisation d’un produit existant ou d’un prototype. Cette implication des utilisateurs doit être à la fois précoce (elle est nécessaire dès les prémices du projet) et itérative (elle doit se répéter tout au long des étapes clés du projet).

22Concevoir une application « ergonomique » est donc un résultat qui découle de méthodologies de conception, et nécessite de se demander à chaque étape critique de la conception si le produit correspond aux besoins des utilisateurs finaux. Cette approche a été traduite en une norme internationale, l’ISO 13407 (Processus de conception des systèmes interactifs centrés sur l’humain) qui vise le cycle de conception et détermine les exigences auxquelles un projet doit répondre pour être considéré comme « centré sur l’humain ». La norme a été complétée en 2000 du rapport technique 18529, et du rapport ISO TR 16982. Ce dernier permet d’identifier quelles méthodes d’utilisabilité sont recommandées à un stade déterminé du cycle de vie, en prenant en considération les éléments de décision habituels d’un chef de projet.

23Dans la CCU, une place prépondérante est donnée à l’utilisateur parfois au détriment des autres acteurs de la conception. Les aspects d’innovation et de gestion avec ce que cela implique en termes de mutation de l’entreprise et d’organisation de l’équipe de conception ne sont pas pris en compte dans cette démarche qui reste ancrée sur le besoin et l’adéquation au besoin. C’est pourquoi, tout en retenant le principe de la collaboration des utilisateurs à la conception, nous examinons maintenant un autre champ, celui de la conception participative.

II . 3. CONCEPTION PARTICIPATIVE

24Les processus de conception participative (CP) se sont développés en Suède depuis les années 1970. Pendant cette période, le gouvernement avait voté deux lois qui donnaient le droit aux employés de participer aux décisions concernant leur milieu de travail. Au début, le droit à la participation était une question de répartition de pouvoir entre l’employeur et le syndicat. La conception participative était donc essentiellement vécue comme une question de démocratie, l’instrument le plus important en étant la législation. Manuels et check-lists ont aussi été développés pour soutenir les employés dans leur collaboration avec l’employeur. Ce modèle a été généralisé à la relation utilisateur/concepteur mais s’est vite stérilisé à cause des rôles conflictuels de donneur d’ordre / marchandage impliqués par le modèle et fondés sur le rapport de force.

25L’étape suivante, dans les années 1980, a été centré sur les connaissances des acteurs et le « recueil du savoir » des usagers. L’état de méfiance et la lutte de pouvoirs qui régnaient jusque-là ont abouti à un accord mutuel sur le fait que les usagers (souvent incarnés par les employés) détiennent une connaissance importante qui pourrait être employée pour augmenter la qualité du produit final. L’usager devenait une source d’information et le client un investisseur qui fait confiance à l’expert pour concevoir un produit adéquat au meilleur prix. Les outils utilisés dans le processus ont alors été conçus pour rassembler et procurer des informations d’une façon structurée. Des techniques de recueil de données, les check-lists et les méthodes d’interviews ont été développées dans ce but. Les experts assuraient le rôle de coordinateurs ou d’animateurs dans les séances de conception. L’institution était représentée par ses propres experts (les concepteurs) et les utilisateurs par les siens (ergonomes, représentants divers, etc.). Malgré des améliorations par rapport au premier modèle des années 1970, celui-ci souffrait encore d’imperfections : les rôles restaient trop différenciés et l’efficacité dans l’élicitation des savoirs n’était pas optimale car les utilisateurs avaient quelques craintes à livrer leur connaissance sans garantie de sa bonne utilisation. Par ailleurs, les experts-ergonomes ne pouvaient se substituer totalement à un véritable panel d’utilisateurs.

26Dans les années 1990, Granath (1996) a introduit le concept de processus de conception collectif pour distinguer une nouvelle dimension de la conception participative, différente de celle considérée pendant les années 1970 et 1980. Un processus de conception collectif est une activité de conception participative où tous les acteurs sont considérés comme experts et leur participation est basée sur leurs connaissances propres plutôt que sur les rôles qu’ils jouent ou les intérêts qu’ils représentent. Il s’agit d’un acte créatif dans un processus collectif auquel contribuent activement, avec leurs différents savoirs, toutes les personnes concernées par le résultat du processus. Ainsi, tous les acteurs au sein d’une compagnie peuvent être considérés comme utilisateurs – et du moins comme utilisateurs intermédiaires. Les consultants externes participent également au processus. Le travail de conception dans un tel processus collectif est donc à la fois pluridisciplinaire et « pluri-hiérarchique ». Il doit être géré comme un travail d’innovation dans l’entreprise pour être opérationnel et efficace.

27Ainsi, la conception participative nous paraît être un cadre intéressant pour la conception innovante. Elle fait intervenir de multiples acteurs dans l’entreprise, dépasse la sphère purement ergonomique et s’étend aux dimensions socio-économiques de l’usage. Elle doit donc être parfaitement maîtrisée dans son déroulement car c’est un phénomène complexe. Pour cela, il est nécessaire de l’instrumenter pour donner à chaque acteur des outils spécifiques qui lui permettent d’observer et de guider son activité pendant le processus – guider ne voulant pas dire planifier, puisque nous sommes ici dans le champ de l’action située (Suchman, 1987).

28Ainsi, la conception participative nous semble plus intéressante pour l’innovation car elle fait intervenir de nombreux types d’acteurs (en plus des concepteurs et des utilisateurs), avec une préoccupation de gestion en arrière-plan, et qu’elle n’impose pas de connaître le but ou le besoin a priori.

29Notre contribution vise donc à formaliser le processus de la conception participative à l’aide de procédures et de schémas adaptés des méthodes plus classiques en conception et en conception centrée utilisateur. Nous donnons une importance accrue aux rôles d’acteurs avec notamment : un acteur pour gérer le « projet d’innovation », tout en pouvant jouer le rôle de régulateur de la communication (Badke-Schaub et al., 2002) ou d’animateur du travail collaboratif de conception (Idemmerfaa et al., 2002). Cependant nous restons dans le champ strict de la conception et nous n’allons pas jusqu’à introduire un gestionnaire du changement de l’organisation de l’entreprise (Béguin, 2007).

III. POSITIONNEMENT DE LA MÉTHODE  DES « MOMENTS »

30Avant d’entrer dans les détails de la formalisation, nous remarquerons que l’ingénierie concourante (Cardon, 1997) (concurrent engineering) a été une forme de réponse à ce problème dont l’approche générale est de réunir des équipes multidisciplinaires autour d’une démarche de développement conjointe. Cette démarche est restée centrée sur la méthode de production et non sur l’innovation. Elle est cependant intéressante dans son niveau de contrôle que nous résumons ici au moyen de RUP (Rational Unified Process) qui est une méthode de prise en charge du cycle de vie d’un logiciel et donc du développement, pour les logiciels orientés objets. C’est une méthode générique, itérative et incrémentale, contrairement à la méthode séquentielle MERISE (ou SADT) citée plus haut. RUP s’appuie sur UML [1].

31Une itération est la succession des étapes d’une activité. Un incrément est une avancée dans les stades de développement. À chaque itération on retrouve les phases de spécification des besoins, d’élaboration, jusqu’au prototypage exécutable. Une nouvelle itération, par exemple après démonstration du prototype aux utilisateurs, reprendra la spécification en la précisant ou la corrigeant, puis reviendra à l’élaboration, etc. PU prévoit un cycle de vie où les itérations (spécification + analyse + conception + implémentation + tests) sont regroupées en catégories d’activités. Ces activités sont soit initiales (création), soit intermédiaires (élaboration, construction), soit finales (transition vers l’utilisateur ou mise en production). Ces catégories d’activité découpent la réalisation du produit comme une succession temporelle (séquences) mais comprennent toutes les tâches structurantes du projet (raffinages successifs, itérations) et proposent une organisation matricielle du volume d’activité total fourni : il est évident qu’en phase de création une plus grande partie du temps sera consacrée à l’analyse des besoins qu’aux tests ; inversement, en phase de transition, les tests sont encore en cours alors que l’analyse des besoins et son raffinage sont théoriquement terminés depuis la phase de construction. RUP nécessite la présence d’un chef de projet qui gère l’ensemble du processus.

32Notre méthode puise dans tous ces travaux et courants de la conception pour en dégager une méthode adaptée à la conception innovante :

33— elle vise l’innovation de rupture car elle ne part pas d’un besoin déclaré par un utilisateur mais seulement d’un marché cible ;

34— elle garde le principe général de la conception participative qui ne privilégie aucun acteur particulier dans la conception et qui travaille sur un mode collectif ;

35— elle peut être formalisée rigoureusement et gérée par un chef de projet comme dans la méthode RUP ;

36— elle reste centrée utilisateur comme dans la CCU en distinguant entre plusieurs types d’utilisateurs [2] et d’acteurs ;

37— elle propose des outils de capitalisation des connaissances et des décisions comme dans TRIZ.

38Avant de formaliser notre méthode, nous avons observé de nombreuses séances de conception participative avec l’intention de mettre en place une gestion efficace du processus : pour cela nous avons tenté d’expliciter les connaissances et les pratiques de ces utilisateurs dans le processus de conception. Puis nous avons fait travailler ensemble des équipes hétérogènes et reconfigurables en mettant en place un ensemble de moyens – en suivant les recommandations de Suchman (1996) – comprenant : des bases de connaissances, des moyens de communication (ordinateurs, PDA), des outils de travail en groupe et des outils de management. Nous avons enregistré les séances qui se déroulaient dans une smart room équipée pour cela. Nous avons ensuite analysé des séances de travail collectives en termes d’activité : pour cela nous avons défini une grille d’observation, découpée en cinq parties : a) l’activité déployée pendant les séances collectives ; b) l’usage des instruments et outils proposés en séance ; c) l’activité de dialogue entre acteurs ; d) les rôles joués à leur insu ou non par les différents acteurs ; enfin, e) les connaissances mises en œuvre. L’ensemble des cas que nous avons recueillis nous ont conduit à une modélisation du processus de conception innovante. La formalisation, les outils de gestion et les outils d’instrumentalisation constituent le support de la méthode – cette nécessité d’outiller le processus de conception qui l’accompagne est également mise en lumière par des travaux récents (Darses et al., 2001).

IV. LES ÉLÉMENTS DE LA MÉTHODE

39Nous définissons les termes qui suivent.

IV . 1. PRIMITIVES

40L’analyse a fait apparaître qu’une séance de travail peut se découper en primitives génériques comme : « informer les participants », « les consulter pour déterminer les fonctions autour desquelles la discussion aura lieu », « faire la synthèse de tous les propos recueillis », etc. Ces primitives constituent des invariants dans le processus de conception : même si les diverses séances de conception ont une structure variable, elles restent articulées sur un ensemble fini de primitives (on peut d’ailleurs retrouver les mêmes primitives à d’autres instants de la conception). Ces primitives apparaissent donc comme des grains élémentaires d’activité. Elle constituent l’ontologie de la tâche de conception.

IV . 2. MOMENTS

41Vis-à-vis de l’avancée de la tâche de conception proprement dite, il y a des « moments » à la fin desquels des résultats sont obtenus, même s’il ne s’agit que de résultats provisoires encore (création d’une maquette, par exemple). Ces moments sont structurés autour des primitives. Nous nommons un tel ensemble moment de la conception – un moment pouvant d’ailleurs se réaliser sur une ou plusieurs séances de conception. Le moment est donc formellement un groupement de primitives liées temporellement et hiérarchiquement dont l’aboutissement mène à une avancée qui prend sens dans la tâche de conception.

IV . 3. PHASES

42Dans son cycle de vie, le travail de conception se présente comme une activité collective réalisée au cours de séances organisées et d’activités individuelles menées en dehors de ces séances. Ce travail de conception est de nature créative et n’est pas planifiable par essence : il passe néanmoins par des phases de conception, chaque phase pouvant à son tour être décomposée en moments. La phase identifie une étape du processus de conception et est marquée par des jalons. Les phases se distinguent par un changement notable de la nature de l’activité (de la conception à l’évaluation, par exemple).

43Le processus de conception est modélisé par un graphe orienté dont les nœuds représentent les moments et dont les arcs représentent les transitions entre deux moments (fig. 1). Les phases sont des ensembles de moments (marqués dans le temps par des jalons). Les primitives sont des activités internes aux moments.

V. MODÉLISATION DES PRIMITIVES, MOMENTS, PHASES ET TRANSITIONS

44Nous décrivons de manière plus détaillée ci-après la modélisation des Moments, Primitives et Phases.

V . 1. MOMENT ET PRIMITIVE

45Définition d’un Moment : C’est un ensemble de tâches de conception ayant une cohérence causale et dont l’exécution conduit à un résultat tangible pour la conception. Il relève d’une organisation à gros grain de la conception, il fait sens vis-à-vis du cycle de vie.

46Définition d’une Primitive : C’est une tâche élémentaire (ou simple action), paramétrable ; par exemple, « s’inscrire à un groupe de travail » est une tâche annexe en conception participative mais bien réelle. Elle se caractérise par son insécabilité et sa généricité – en effet, elle est réutilisable dans tous les processus de conception si nécessaire.

47Exemple d’articulation entre primitive et moment : soient les primitives {brassage d’idées (x)} et {sélection d’idées (y)} où x et y sont des arguments. Ces primitives prennent un sens dans le processus de conception si l’objet x du brassage d’idées et de la sélection d’idées y est non seulement le même (x = y), mais également si x = obj où obj est un objet de la conception (un artefact, par exemple). La séquence {brassage d’idées (obj) SEQ sélection d’idées (obj)} peut alors constituer le corps d’un moment {et devenir une séance de créativité}. L’opérateur SEQ indiquant une contrainte de précédence (ici séquence) entre les primitives.

48Moments et primitives sont formalisés en UML par un « objet » de même structure comprenant les champs suivants :

49Identificateur du moment / primitive : Description courte (quelques mots) en langage naturel du moment/primitive. Un moment/primitive peut disposer, dans son identificateur, de paramètres formels en entrée/sortie. L’usage de paramètres est principalement utilisé pour les primitives mais peut l’être aussi pour les moments.

50Fonction d’application : Indique si le moment/primitive peut être répété (par exemple. [1] : une fois ; [ sessions] : cumul de sessions ; [K utilisateur] sur un ensemble d’utilisateurs).

51Objet (but ou objectif) : Description longue (quelques lignes) en langage naturel qui précise l’identificateur du moment/primitive.

52Acteurs : Liste d’acteurs dont la présence est nécessaire au bon déroulement du moment/primitive. Il peut être précisé des acteurs optionnels, plusieurs acteurs du même type, un intervalle (minimum, maximum, typique) ou encore plusieurs configurations possibles. Les acteurs se réfèrent à des catégories d’acteurs (par exemple : ergonome, utilisateur final, etc.) et non à des personnes.

53Entrée (prérequis) : Ensemble des éléments (documents, artéfacts) nécessaire au bon déroulement du moment/primitive.

54Corps (Procédure) d’un moment : Ensemble de primitives constituant l’activité des participants au cours du moment. Les primitives sont liées par des opérateurs temporels :

55• SEQ : ordre obligatoire entre deux primitives ;

56• OU : alternative entre deux primitives ;

57• ET : ordre libre entre deux primitives ;

58• SI (cond) : condition nécessaire à l’exécution d’une primitive.

59Sortie (post-requis) : Ensemble des éléments (documents, artefacts) qui seront produits par le moment/primitive. On n’indique pas dans les post-requis les éléments non produits explicitement par le moment.

V . 2. TRANSITION

60Le séquencement des moments dans le processus de conception se base sur deux concepts : les pré/post-requis et les transitions. Leurs rôles sont sensiblement distincts :

61— Les pré- et post-requis permettent de déterminer les possibilités d’enchaînement des moments en fonction des documents et artefacts produits (post-requis) et ceux qui sont nécessaires (pré-requis). Ces pré- et post-requis définissent un ensemble d’enchaînements possibles ; une succession est valide si un moment produisant une donnée en sortie est antérieur à un moment utilisant cette donnée en entrée.

62— Les transitions matérialisent, quant à elles, les choix de successions possibles entre les moments. Elles indiquent non pas seulement les enchaînements possibles, mais ceux souhaités par les acteurs dans le processus. Bien entendu, les transitions doivent impérativement respecter la dépendance des pré- et post-requis de chacun des moments utilisé effectivement dans le processus.

63Définition d’une Transition (fig. 2) : lien entre moments exprimant une séquence d’exécution souhaitée. Cette précédence temporelle doit être cohérente avec les pré- et post-requis des moments.

64Une transition est modélisée par un « objet » UML comprenant :

65Identificateur de la transition : Description courte (quelques mots ou commentaire).

66Conditions à satisfaire : Ensemble des conditions, nécessaires au passage d’un moment à un autre. Ces conditions sont exprimées en langage naturel.

67Choix ou décision : Ensemble des éléments ayant entraîné un choix (par exemple, choix parmi deux moments suivants) ou une décision (par exemple, omission d’un moment). Cette information est indiquée dans un but ultérieur de traçabilité des décisions.

68Paramètres à transmettre : Documents et/ou artefacts effectivement transmis entre les deux moments.

69Moment initial et moment final : Indication des moments initial et final de la transition (information redondante si la transition est notée sous forme graphique, comme indiqué fig. 2).

70Opérateur de choix origine/destination : Indication si un choix est possible quant à la poursuite du processus. L’opérateur prend typiquement la valeur ET, OU.

V . 3. PHASE

71Définition d’une Phase (fig. 1) : Elle est marquée par un point de passage de la conception (jalon) ou un instant particulier situé dans le temps (borne). La notion de phase renvoie à celle de chronogramme et, partant, à celle d’organisation temporelle du projet de conception.

72La phase est constituée d’un ensemble de moments. À ce titre, la phase peut être vue comme un sous-ensemble de moments du processus de conception. Les moments d’une phase ne sont pas nécessairement liés par des transitions. En effet, une même phase peut être constituée de moments exécutés en parallèle, donc sans liens explicites entre eux. La principale caractéristique de la phase est qu’elle identifie une étape dans le cycle de conception et que les phases se distinguent par un changement notable de la nature de l’activité.

VI. DÉMARCHE INTÉGRATIVE

77Le formalisme précédent nous a permis de mettre au point un modèle général et intégratif permettant d’inclure les préoccupations des sociologues, ergonomes et/ou des économistes dans le cycle de conception. Cela se représente par des moments particuliers pouvant prendre place à n’importe quelle phase de la conception, comme moments de négociation entre les acteurs. Ces moments sont construits sur des primitives métiers, réutilisables.

78Par exemple, voici la formalisation de moments pour la phase « test du consentement à payer » utile pour un économiste dans le projet d’innovation :

79On obtient une représentation similaire avec des moments liés à des aspects sociologiques, par exemple ci-après un moment de créativité :

VII. INSTRUMENTATION DE LA CONCEPTION

80Il existe différentes pratiques organisationnelles d’un processus de conception : il ne s’agit pas ici de révolutionner ces pratiques – au demeurant fort diverses selon le type de produits/services, le type d’institution, les habitudes socioculturelles des acteurs, le type d’organisation de l’entreprise, etc. –, mais de proposer un ensemble d’outils prenant place dans une plate-forme pour assister méthodologiquement et accompagner techniquement le processus de conception. Pour cela nous restons à un niveau générique qui est celui d’instrumenter les moments et les primitives, et elles seules. Il faut également capitaliser les connaissances durant les transitions dans un souci de réutilisabilité d’expériences et comme jalons de la conception. Ces connaissances portent donc surtout sur les décisions prises par les acteurs.

81L’assistance au processus de conception participative nécessite aussi de donner des moyens d’intervention et de communication aux acteurs de la conception pendant et hors séance collective. Étant donné la diversité de ceux-ci et leurs niveaux de compétence très différents, il nous paraît que les séances collectives doivent être encadrées par un animateur pour faciliter la communication, arbitrer les conflits, gérer les discussions et la progression du travail. En arrière-plan il est nécessaire d’enregistrer les séances, d’analyser les données pertinentes puis de capitaliser les connaissances extraites, de façon à : a) tracer les interventions de chaque acteur ; b) archiver les décisions et les choix effectués pour un suivi plus efficace du processus ; et c) constituer un mémoire de cas d’expériences utile dans un autre processus.

82Le but est donc d’instrumenter les séances de travail collaboratif en conception participative en améliorant les échanges entre les acteurs et en leur fournissant :

83• un cadre de travail dépendant des moments de la conception ;

84• des mécanismes de régulation (de la prise de tour de parole, des droits intellectuels, etc.) ;

85• une base d’expériences antérieures d’utilisation des moments de la conception ;

86• un support d’échange de connaissances structurées ;

87• un cadre matériel de communication et de travail.

88Cela peut être schématisé par la figure 3, où l’on distingue quatre opérations principales :

89La capture : les acteurs sont placés dans une salle de conception dite « intelligente » (en anglais, smart-room) équipée de caméras, écrans, micros, capteurs de présence, etc., dans laquelle tous les faits, gestes et parole sont enregistrés.

90L’archivage : les données (audio, vidéo, informatiques) sont filtrées, sélectionnées, synchronisées et annotées par un observateur invisible des acteurs en cours de séance de travail.

91L’analyse de l’activité de conception : elle est effectuée selon un canevas prédéterminé en phases et moments.

92L’extraction des connaissances : c’est un processus d’organisation des concepts et des décisions prises dans la séance ou entre deux moments. Ces connaissances sont mises sous forme de réseaux sémantiques et sont attachées aux transitions. On y trouve :

93— les raisons de décision (critères et arguments) ;

94— les choix de décision (compte rendu) ;

95— les conséquences attendues (moments choisis pour continuer) ;

96— la validation (jalons atteints, phases terminées) ;

97— les correctifs en cas d’impasse.

98Les connaissances peuvent dès lors être représentées par un objet « décision » dont la structure générale est :

99— Quand (moment_i, date) ;

100— Qui (proposé par, décidé par) ;

101— Objets concernés (artefacts) ;

102— Critères ou contraintes à satisfaire ;

103— Options possibles ;

104— Arguments pour chaque option ;

105— Solution retenue ;

106— Explications du choix ;

107— Conséquences attendues (moment suivant) ;

108— Actions (tâches, contrôle, jalons, correctifs) ;

109— Liens_base (cas, contexte).

110L’usage des informations recueillies permet :

111— au chef de projet de négocier le processus de conception autant avec le donneur d’ordres qu’avec les acteurs en s’appuyant sur les moments enregistrés et les expériences passées ;

112— à l’animateur de préparer les séances de travail et d’en assurer le suivi ;

113— aux acteurs d’avoir une vision sur le processus et les connaissances selon leur niveau de compétence ;

114— à l’observateur, chargé de l’archivage et de l’annotation des enregistrements, d’avoir un cadre de référence ;

115— au gestionnaire de projet d’avoir un suivi de l’évolution du projet et des besoins des acteurs ;

116— aux spécialistes des sciences humaines et sociales de disposer de corpus annotés.

VII . 1. LE MODÈLE CONCEPTUEL

117La formalisation du modèle conceptuel a été réalisée avec la syntaxe d’un diagramme de classes UML (fig. 4). La modélisation a été validée à l’aide de l’ensemble des exemples de phases, moments et primitives spécifiés.

118Cependant, il est vite apparu qu’il était plus important de présenter à l’utilisateur les concepts de manière graphique que de vérifier de manière formelle les contraintes du modèle. C’est pourquoi notre choix s’est porté vers la réutilisation d’un outil visuel d’aide à la planification ayant des capacités d’hypertexte plutôt que vers la création d’une base de données relationnelle. Nous avons choisi pour cela un logiciel commercial (MindManager^®).

VII . 2. MINDMANAGER®

119MindManager^® est un logiciel commercial permettant de faire du « Mind Mapping », c’est-à-dire de la représentation des connaissances sous forme de concepts et de réseaux. Chaque concept, représenté par un nœud, peut être relié par hypertexte à un autre concept ou à un élément (document, programme, lien Internet, ressource multimédia, etc.). Le logiciel dispose, pour la majorité des types de documents usuels, d’un éditeur (ou simplement lecteur) intégré sous forme de plug-in permettant à l’utilisateur de modifier (ou simplement lire) le document dans le logiciel, donnant ainsi l’impression à l’utilisateur de disposer d’un environnement d’édition complètement intégré. MindManager^® dispose également du concept de morceaux de carte map part permettant de simuler le mécanisme d’instanciation. En effet, des morceaux de cartes peuvent être créés par les utilisateurs et rangés dans une bibliothèque. Ils sont alors réutilisables à souhait dans de nouvelles cartes. En outre, certains liens portent une sémantique (succession des tâches) et permettent ainsi d’extraire des schémas spécifiques à la gestion de projet (diagramme de Gantt).

120Dans notre paramétrage spécifique de MindManager^®, nous avons représenté les moments capitalisés sous la forme de morceaux de cartes créés par les experts et réutilisables par les utilisateurs pour de nouveaux projets.

121Les morceaux de cartes représentant les moments sont créés par les experts (ergonomes, sociologues, chefs de projet...) à l’aide d’un assistant. L’objet du moment, ses entrées, ses sorties, ses acteurs sont renseignés par les experts et reliés au morceau de carte du moment, ainsi que d’éventuelles ressources spécifiques à ce moment (guide pour appliquer la méthodologie, outil de support à la conception participative, conducteur de réunion, modèle de document, etc.).

122Ces morceaux de cartes sont ensuite mis à disposition des utilisateurs dans la bibliothèque. Les nouveaux projets, créés par les utilisateurs à partir des moments de bibliothèque, sont eux-mêmes stockés dans une carte spécifique aux projets. Au cours du projet, l’utilisateur fait appel à ses moments instanciés comme fil conducteur de son activité et aussi comme source de connaissance ou de modèles. Une fois terminé, le projet et ses moments instanciés sont capitalisés et, de ce fait, réutilisables pour d’autres projets.

VII . 3. CAPITALISATION DES CONNAISSANCES

123Dans la pratique, la structure générale des données et connaissances est organisée à partir d’une racine qui permet d’accéder à la base globale, découpée en quatre parties :

1241 / Moments : base des moments (décrit le savoir-faire) ;

1252 / Projets : base des projets déjà exécutés et en cours d’exécution ;

1263 / Ressources humaines : base des personnes et de leurs rôles dans les projets ;

1274 / Relations industrielles : portefeuille d’adresses et de contacts.

128Les projets en cours d’exécution sont gérés à travers une représentation en diagramme de Gantt. Ceux qui sont achevés sont capitalisés en distinguant les connaissances de type retour d’expérience des connaissances factuelles (c’est-à-dire présentations, rapports, relevés de décision, etc.).

129Un projet achevé est archivé en rubriques, les SP (sous-projets), les rapports, le contrat, la présentation. Chaque partie est découpée en moments, avec par exemple, sur la figure 5 : « Analyse de la concurrence », « Élaboration de concept », « Créativité », « Conception participative » (dans laquelle on distingue diverses séances), « Résultat de conception » et « Enquête d’usage ». Dans le moment « Créativité », par exemple, on a détaillé les séances de préparation et de travail à partir du schéma général de « Créativité », d’une part, et des faits et événements qui se sont déroulés dans un autre projet nommé Stylocom, d’autre part.

130Les moments incarnent des connaissances procédurales générales indépendantes des projets particuliers eux-mêmes. Ils comportent des données partagées et des données privées de certains acteurs, telles que mémos, notes personnelles, savoir-faire, etc. Les données partagées sont conformes aux descriptions formelles données dans la partie précédente complétées par des données spécifiques comme des fiches d’aide pour faire des exercices, des outils à lancer, des modèles de rapports ou de contrats, etc. La figure 6 donne un exemple de moment appelé « Brassage d’idées ».

131Le chef de projet organise les moments dont il a besoin pour conduire un projet en cours d’exécution. Il les enchaîne dans un diagramme Gantt et les valide avec l’équipe-projet à la fin de chaque moment. Il fait également un suivi en temps réel de l’évolution du projet et des connaissances mises en œuvre (données, faits, événements, décisions, etc.). Il dispose de la base des personnes qui contient l’ensemble des ressources humaines affectées aux projets. Un exemple est donné sur la figure 7.

VIII. USAGE DE LA MÉTHODE ET ÉVALUATION

132L’usage de la plate-forme instrumentée concerne surtout le chef de projet-conception qui initialise le projet avec un client et qui suit l’évolution du processus de conception tout au long du projet de manière dynamique.

133L’usage de la plate-forme concerne également les acteurs de la conception :

134— l’animateur, qui doit y trouver un espace de travail personnel, un accès à la base des moments et au workflow des moments, un accès aux documents ou rapports, à la cartographie des compétences ;

135— les acteurs de la conception (concepteurs, utilisateurs, etc.), qui doivent y trouver la cartographie des compétences, accéder au workflow des moments et aux expériences de conception, et plus généralement à leurs données personnelles ou à des données venant du Web, en même temps qu’à un espace de travail collaboratif ;

136— l’observateur, qui doit pouvoir accéder aux outils d’annotation, aux consignes et critères d’annotation ou d’observation, à une zone partagée de commentaires et éventuellement à un espace de travail privé ;

137— le spécialiste en SHS, qui doit pouvoir accéder à la base des moments, aux événements annotés et aux documents de prises de décision  ;

138— le gestionnaire de la plate-forme, qui doit y trouver les moyens de gérer les outils et toutes les sources de données ou informations.

139Enfin, l’usage de la plate-forme concerne aussi les décideurs et le client, ils doivent pouvoir avoir accès aux rapports de prise de décision et au rapport final.

IX. CONCLUSION

142Notre méthode met en œuvre divers principes dans le champ de la conception (conception participative surtout) en tentant de formaliser la conception pour un processus d’innovation. Nous aboutissons à des représentations certes un peu complexes mais qui s’appuient sur des outils utilisables par tous les acteurs à leur niveau de besoin et de compétence. Le chef de projet dispose ainsi d’un système de suivi, de gestion et d’anticipation du projet d’innovation, l’animateur(s), l’observateur(s) et les autres acteurs de tous les documents et connaissances dont ils ont besoin pour leur travail de conception collective ou individuelle. La capitalisation des décisions évite les retours arrières et les pertes de temps inhérentes à tout travail collectif.

143Manuscrit reçu : mai 2008. Accepté après révision par les coordinateurs : novembre 2008.