Choix, décisions

Durant la conception préliminaire, plusieurs choix sont à valider, afin de passer aux phases suivantes : sélection de concept, choix de concept de solution, détermination de composants et choix d'architecture, etc. Chaque décision de conception change l'état de la conception [Ull 03] et la description du produit s'enrichie.

Sawada citant Andreasen, illustre les "degrés de liberté de conception". L'espace des solutions de conception s'élargi de manière pyramidale (Figure 18), et il est exploré pour

chaque concept, jusqu'à ce qu'une solution de conception soit trouvée. Durant l'exploration des alternatives de conception, le concepteur prend des décisions comme la détermination de valeurs pour des paramètres de conception. Afin d'obtenir une solution de conception optimale, il est nécessaire pour le concepteur d'explorer les alternatives générées par les différentes options de décision, et de les comparer [Saw 01a].

Problème Processus

Fonctions Principes

Structure organique Structure des assemblages

Matériaux Dimensions

Qualité de surface Détails de forme Forme des éléments

Figure 18: Elargissement de l'espace des solutions de conception.

Le concepteur réalise des choix en appliquant les connaissances qu'il possède et en prenant en compte les contraintes qu'il perçoit [Bel 01]. Les connaissances de conception peuvent être vues comme un savoir implicite obtenu grâce à l'expérience, ou bien un savoir explicite (théories, méthodologies, modèles de conception, etc.) [Rey 01].

Alors que la conception avance, de plus en plus paramètres de conception sont introduits pour décrire des solutions de conception avec plus de précision. Pour choisir des options optimales les concepteurs doivent prendre beaucoup de décisions basées sur des intuitions ; les rapports entre les paramètres de conception sont souvent sous-jacents [Saw 02].

Ainsi, les pratiques sont souvent basées sur des habitudes [Mat 02]. L'expérience et le savoir faire influencent fortement la compétence des concepteurs dans la création d'objets techniques [Hub 01]. C'est notamment le cas pour l'évaluation de la faisabilité d'un concept; qui est basée sur l'expérience et les connaissances des concepteurs [Ull 03].

Cela correspond aux comportements "machinal" ou "procédural", décrits par Leroy et

Signoret (voir §2.1.1). Parfois même, le concepteur se dirige directement vers une solution

qu'il maîtrise; il y a prégnance de la solution dans le processus mental de conception [Dar 00]. Des alternatives intéressantes peuvent être écartées parce qu'elles ne sont pas connues, usuelles ou évaluées.

Les habitudes peuvent provenir du comportement machinal d'un concepteur, ou s'imposer comme des règles naturelles dans une entreprise, un bureau d'étude : certains types de solutions font partie de la culture de l'entreprise. Déroger à ces règles est considéré comme un risque.

Dans tous les cas, les architectures solutions sont fortement dépendantes de ces décisions [Hic 02c].

Plusieurs décisions s'exercent aux différents niveaux du processus de conception : Pour ce qui est de l'évaluation des concepts, Ullman précise que souvent seul le concept qui semble être le plus prometteur est développé : cela évite d'après lui de passer du temps à structurer les concepts, à les rendre mesurables pour qu'ils puissent être comparés vis-à-vis des objectifs de conception et des spécifications. La difficulté dans l'évaluation de concept c'est que l'on dispose de connaissances et données très limitées sur lesquelles baser la sélection [Ull 03].

Même si des méthodes et outils existent, comme les matrices QFD qui permettent une comparaison de concepts au regard de différentes fonctions, la sélection de concept est une étape critique car toutes les activités suivantes en dépendent [Che 02].

Le Coq souligne le caractère combinatoire de la recherche d'architecture et le nombre important de solutions qui en résulte. Cet auteur propose d'explorer les différentes combinaisons possibles d'éléments. Ensuite, l'évaluation des différentes solutions d'architectures doit impliquer les différents acteurs métiers. Cette évaluation est plutôt qualitative et positionne les solutions par rapport à l'existant [LeC 92].

Une fois que l'on dispose de plusieurs architectures réalisables, il faut être capable de choisir donc de les hiérarchiser.

Aussi bien pour le choix d'un concept que durant la détermination d'architecture, des décisions sont basées sur l'intuition et l'expérience des concepteurs, sur les habitudes personnelles ou collectives.

Il est nécessaire de faciliter le choix parmi plusieurs concepts. Nous ne prétendons pas réaliser la sélection de concept. Mais, une fois que des concepts pertinents ont été retenus, nous proposons de faciliter le choix parmi plusieurs alternatives, plusieurs concepts de solution.

Par ailleurs, le système d'aide à la décision doit fournir au concepteur l'ensemble des architectures solutions et un moyen de les discriminer.

2.3.3 Itérations

La démarche de conception de produit est intrinsèquement itérative [Qua 94][Roo 95][Sco 96]. Beaucoup de modèles de processus de conception prévoient d'ailleurs, implicitement, des boucles de retour en arrière [Tat 96][Rey 01]. A chaque niveau de la conception, le processus est itératif et récursif, et fourni un progrès incrémental du problème [Woo 01].

La conception de produit est au cours du projet une série d'aller-retour. Le phénomène d'itération est une caractéristique fondamentale de l'acte de conception de produit selon Vadcard [Vad 96]. Il préconise d'intégrer l'aspect itératif dans la programmation de l'action, plutôt que de la considérer comme un phénomène perturbateur dû à des erreurs de choix.

Les itérations proviennent de la recherche d'architecture. Entre la recherche de concepts ("conceptual design") et la conception architecturale ("embodiment design"), plusieurs itérations sont nécessaires pour faire émerger la conception définitive [Pah 96].

De plus, il existe une séquentialité dans la détermination des caractéristiques de l'architecture. Il est souvent nécessaire de connaître les paramètres d'un élément pour en déterminer un autre. Avec les outils traditionnels d'analyse assistée par ordinateur, les calculs et simulations se font avec des définitions avancées du produit; les concepteurs emploient souvent une approche essai-erreur basée sur des méthodes numériques. Elle produit quelques valeurs solutions sans donner les relations fondamentales entre les paramètres de conception. [Saw 01b].

La conception architecturale induit un processus itératif de génération d'artefacts de produits et d'évaluation de leur capacité à satisfaire les exigences [Ull 03].

Janssen citant Amarel [Jan 90] indique qu'une utilisation a posteriori des spécifications pour évaluer une conception correspond à la méthode "générer et tester" puisque l'évaluation a lieu lorsque la structure de l'objet est entièrement définie.

Les itérations résultent donc également du mode essai-erreur, induit par la causalité dans la détermination des caractéristiques de l'architecture.

Des choix réalisés a priori induisent un mode "essai-erreur" de détermination d'architecture. Les connaissances nécessaires à la conception d'un produit qui réponde aux multiples exigences ne sont pas toujours toutes prises en compte.

Nous souhaitons avec notre approche limiter les itérations ; il faut donc être capable de lister ces connaissances. La recherche de toutes les architectures réalisables doit toutes les prendre en compte simultanément.

2.4 Difficultés en conception préliminaire

Beaucoup d'auteurs le soulignent, il existe peu d'outils et de procédures permettant de supporter cette phase du processus de conception.

Selon Antonsson, il est difficile de fournir des outils informatisés pour les premières phases de la conception de produit [Ant 01], notamment lorsque les concepteurs souhaitent comparer les coûts de différentes configurations [Hic 02b].

L'intégration des outils KBS (Knowledge Based Systems) dans les premières phases de la conception architecturale n'est pas encore satisfaisante [Wel 99].

Suite aux pratiques que nous venons de décrire, nous allons voir les difficultés qu'elles engendrent. Elles seront illustrées dans l'application développée dans le Chapitre 6.