L’analyse des besoins dans les projets de conception et d’innovation

L’analyse des besoins dans les projets de conception et d’innovation

Dans un premier temps nous souhaitons clarifier les termes que nous allons utiliser tout au long de notre document. Il est parfois difficile d’obtenir un langage commun entre les disciplines (marketing, ingénierie, ergonomie…) mais aussi entre les traductions (ici français/anglais). Le terme le plus important de notre document est celui de « besoin ». Les synonymes que nous pourrions lui trouver dans la littérature scientifique francophone sont « attente », « exigence » ou encore « désir » (Loup Escande, Burkhardt & Richir, 2013). Ces termes semblent cependant renvoyer aux mêmes idées, recueillir et anticiper ce que veulent les utilisateurs. Pour les publications anglophones, les deux termes récurrents sont « Requirement » (traduit en Français par « besoin » ou « exigence ») et « Need » (traduit en Français par «besoin » ou « attente »). Si nous reprenons l’analyse terminologique d’Eodice, Leifer et Fruchter (2000), reprise et développée par Arikoglu (2011), le terme «Need» correspond aux désirs des utilisateurs et le terme « Requirement » est défini comme la réponse aux désirs des utilisateurs que l’on transforme en fonction. Pour parler d’analyse des besoins en ingénierie, on parlera principalement de Requirements Analysis mais également de Needs Analysislorsque le processus est centré principalement sur l’utilisateur (Smith, 2011). La flexibilité sémantique des termes précédemment énoncés, liée notamment à la discipline, nous montre qu’il n’est pas facile d’adopter un langage commun exempt d’ambigüité.

Pour notre exposé nous allons suivre le processus linéaire d’analyse des besoins proposé par des Mesnards (2007) : le recueil des besoins utilisateurs, la traduction des besoins en fonctions produit puis le développement de solution (voir Figure 1). Un besoin peut être défini comme étant une « exigence née d’un sentiment de manque, de privation de quelque chose qui est nécessaire à la vie organique : Besoin de manger, de dormir », cela correspond à la première définition présente dans le dictionnaire Larousse. Cette définition renvoie au premier étage de la pyramide de Maslow (1943) : les besoins physiologiques de base. C’est dans la seconde et la troisième définition du dictionnaire Larousse que l’on se rapproche de ce qui nous intéresse dans nos travaux, le besoin comme « sentiment de privation qui porte à désirer ce dont on croit manquer ; nécessité impérieuse : Besoin desavoir» et comme « une chose considérée comme nécessaire à l’existence : Le cinéma est devenu chez lui un besoin ». Le besoin résulte alors d’un manque ou d’une insatisfaction que l’individu cherche à combler. Si l’on se rapproche de la littérature de l’ingénierie nous trouvons la norme NF EN 16271 où le besoin est « ce qui est nécessaire à l’utilisateur ou désiré par lui ». Cette norme caractérise plusieurs types de besoins : explicites ou implicites ; existants ou potentiels (correspondant aux attentes identifiées, non identifiées ou implicites). « Dans tous les cas il constitue le besoin à satisfaire pour lequel un utilisateur est prêt à faire un effort » (Tassinari, 2006). Les fonctionnalités et le produit lui-même répondent alors aux besoins des utilisateurs.

Qu’il s’agisse du modèle de French (1985), du modèle de liaison en chaîne de Kline (Kline & Rosenberg, 1986), des modèles en cascade, en V ou en spirale (Royce, 1970 ; Boehm, 1988 ; Forsberg & Mooz, 1991), de celui de Pahl et Beitz (1996), ou encore de celui d’Aoussat en conception innovante (Aoussat, 1990 ; Duchamp, 1999), tous ces modèles débutent par une phase d’analyse des besoins (parfois appelée différemment comme « marché potentiel » chez Kline ou « planification et clarification de la tâche » chez Pahl et Beitz). La définition que chaque auteur place derrière cette première étape peut cependant différer quelque peu, privilégiant par exemple parfois l’analyse des besoins clients ou parfois l’analyse des besoins des utilisateurs. Nous pouvons identifier trois types de besoins différents dans la littérature (Maiden, 2008 ; Parker, 2012) : les besoins de l’entreprise (Business Requirements), les besoins des utilisateurs (User Requirements) et les besoins du système (System Requirements). Ces trois catégories de besoins pouvant être analysées conjointement dans certains modèles : la première catégorie nous donne les objectifs du projet, la seconde catégorie requiert un recueil des besoins auprès des utilisateurs débouchant sur des fonctions (ou spécifications) puis des solutions correspondant à la troisième catégorie de besoins (des Mesnards, 2007).

Les besoins de l’entreprise (Business Requirements) : 

Les besoins de l’entreprise correspondent aux enjeux et objectifs du projet. Pourquoi l’organisation s’est lancée dans ce projet ? Quelles sont ses attentes ? A-t-elle besoin de résoudre un problème technique, de profiter d’une opportunité de marché? Etc. Les objectifs du projet doivent être identifiés en amont (Robertson, 2001) : le type de produit à développer, les contraintes (budgétaires, temporelles, légales…) ou encore l’identification des parties prenantes (du côté des concepteurs et du côté des futurs utilisateurs). Cette étape est plus ou moins formelle mais peu prendre la forme d’une étude de faisabilité et/ou d’opportunité pour aboutir à un rapport détaillé (NF ISO 21500 ; Sommerville, 2006). O’Shaughnessy (1992) identifie plusieurs composantes relatives aux études de faisabilité, elles peuvent porter sur le marché (marché potentiel, positionnement des concurrents…), sur la technique (capacité de production, matériaux à utiliser…), sur les ressources humaines (main d’œuvre requise…), sur les finances (financement du projet, évaluation de la rentabilité…) et enfin sur la législation (impacts environnementaux, réglementation relatives aux exportations et importations…).

Les besoins utilisateurs (Users Requirements ou Needs) : 

Nous pouvons considérer trois types de besoins utilisateurs (Robertson, 2001 ; LoupEscande, Burkhardt & Richir, 2013) :

➤ Les besoins conscients (conscious) : Ce sont des besoins explicitement énumérés par les utilisateurs, résultant de leur expérience avec les produits. Il peut s’agir de besoins liés à une personnalisation du produit (ex : possibilité de changer la couleur), d’une correction d’un défaut identifié (ex : mise en veille intempestive) ou encore d’une évolution lorsqu’une nouvelle technologie est arrivée sur le marché (ex: écran 4K sur son téléviseur). Ces informations peuvent être obtenues à travers les méthodes « classiques » de l’analyse des besoins : étude de marché, questionnaires auprès des utilisateurs…etc.

➤ Les besoins non conscients (unconscious) : Ce sont des besoins relativement difficiles à détecter. Le produit peut exister (ex : un micro-onde), mais pourrait être amélioré (ex : ajout d’une fonction qui permettrait de réchauffer sa nourriture d’une manière homogène). Robertson (2001), avance plusieurs raisons pouvant expliquer ces « omissions » : l’automatisme ou l’habitude dans l’utilisation de certains produits, le sentiment d’expertise vis-à-vis d’une catégorie de produit ou au contraire la méconnaissance des domaines technologiques. Les méthodes comme les Jeux de rôle ou les Scénarios pourraient permettre d’identifier et développer ces besoins .

➤ Les besoins latents (undreamed) : Ce sont des besoins que nous pouvons considérer comme insoupçonnés par les utilisateurs, voire même inimaginables. Les besoins de cette catégorie apparaissent lors de la mise sur le marché d’innovations de rupture, comme le téléphone portable ou le walkman. Les utilisateurs n’avaient alors pas conscience de l’utilité des dits produits avant de les posséder. Pour Spérandio (cité par Anastassova, 2006) « on propose un système…parce qu’on sait le faire, en faisant l’hypothèse qu’il répond à un besoin ». Nous pouvons alors nous considérer dans une démarche Techno Push, mais également Need Seekers où la prospection des besoins utilisateurs devient un moteur pour l’innovation . Ce sont ici les méthodes de prospection et d’innovation qui priment pour l’identification de ces besoins : créativité, méthode des Personas…etc.

Selon la norme NF X50-100, ces besoins peuvent être classés en deux catégories, ceux relevant de critères objectifs et ceux relevant de critères subjectifs : les besoins objectifs des utilisateurs sont quantifiables, cela peut être le besoin de performance pour une automobile (en km/h par exemple) ou d’autonomie pour un baladeur mp3 (en heure). Les besoins subjectifs sont au contraire plus difficilement quantifiables car ils correspondent à des critères émotionnels ou affectifs : l’esthétisme, la marque, le confort, l’appartenance sociale…etc. Leur analyse reposera sur la création de mesures adéquates comme des échelles ordinales ou nominales. Maguire et Bevan (2002), envisagent l’analyse des besoins utilisateurs d’une manière chronologique : récolte d’informations générales, identification des besoins utilisateurs, évaluation des besoins et spécification des besoins. Cette dernière étape aboutit aux besoins du système.

Les besoins système (System Requirements) : 

Il existe également dans la littérature une différenciation des besoins relatifs au système lui-même, ce sont les besoins fonctionnels et non-fonctionnel (Robertson, 2001 ; Sommerville, 2006). Les besoins fonctionnels correspondent aux fonctions ou aux services offerts par le système : ce que le système doit faire et ce qu’il ne doit pas faire tout en prenant en compte l’environnement et les utilisateurs (ex : pouvoir prendre des photos sous l’eau avec un APN). Les besoins nonfonctionnels concernent l’efficacité des fonctions et des services offerts. Il ne s’agit pas seulement de remplir une fonction mais il s’agit de la remplir efficacement (ex : la performance d’un APN waterproof dans l’obscurité). Il peut s’agir également des caractéristiques d’utilisabilité, de confort, de sécurité, de législation etc. (Robertson, 2001). Ces définitions sont assez proches des termes fonctions principales, contraintes et complémentaires de l’analyse fonctionnelle (NF EN 16271 et NF X50-100). Cette catégorie de besoins débouche alors sur des fonctions à intégrer dans le cahier des charges avant de développer des solutions de conception .

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport-gratuit.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

1. Introduction générale
1.1 Thème de recherche
1.2 Problématique de la thèse
1.3 Structure du document
2. L’analyse des besoins dans les projets de conception et d’innovation
2.1 Introduction
2.2 L’analyse des besoins comme moteur de l’innovation
2.2.1 La culture de l’innovation en entreprise
2.2.2 Les utilisateurs dans le processus innovant
2.2.2.1 La Modélisation des utilisateurs (implication informative)
2.2.2.2 La Conception Centrée Utilisateur (implication consultative)
2.2.2.3 La Conception Participative (implication participative)
2.2.3 Utilisateurs vs Innovation
2.3 Les principales méthodes pour l’analyse des besoins utilisateurs
2.3.1 Conception pour les utilisateurs (Design for)
2.3.1.1 L’Analyse Fonctionnelle
2.3.1.2 Le Benchmarking
2.3.1.3 Les outils de Créativité
2.3.1.4 Les méthodes EPMcreate et POEPMcreate
2.3.1.5 Les Personas
2.3.1.6 La Netnographie
2.3.1.7 L’Analyse documentaire
2.3.2 Conception avec les utilisateurs (Design with)
2.3.2.1 L’Analyse de marché
2.3.2.2 La méthode QFD
2.3.2.3 Le Modèle de Kano
2.3.2.4 Les méthodes Conversationnelles
2.3.2.5 Les méthodes Observationnelles
2.3.2.6 Les Scenarios et Story-boards
2.3.2.7 L’Approche Ethnographique
2.3.2.8 Le Tri de cartes
2.3.3 Conception par les utilisateurs (Design by)
2.3.3.1 La méthode des Lead-users
2.3.3.2 Les Jeux de Rôles
2.3.3.3 La Simulation
2.3.3.4 Le Journal de bord (Diary Keeping)
2.3.4 Conclusion sur la présentation des principales méthodes en analyse des besoins
2.4 Le courant de l’ergonomie prospective
2.4.1 La prospective au service de l’innovation
2.4.2 La pluridisciplinarité de l’équipe de conception comme facteur clé de l’innovation
2.4.2.1 Les principaux métiers de la conception
2.4.2.2 Les profils de personnalité des concepteurs
2.4.3 Favoriser l’efficacité de l’anticipation des besoins à l’aide de technologies support
2.4.3.1 L’exemple de la créativité
2.4.3.2 La créativité sur support électronique
2.4.3.3 La créativité dans des mondes virtuels
2.4.3.4 La ludogénéité des technologies support
2.5 Conclusion
3. Problématique et hypothèses de recherche
3.1 Constats et bilan de notre état de l’art
3.2 De la problématique aux hypothèses de recherche
3.3 Présentation des expérimentations
4. Expérimentations
4.1 H1 et Expérimentation 1
4.1.1 Etude 1
4.1.1.1 Participants
4.1.1.2 Matériel
4.1.1.3 Procédure
4.1.1.4 Variables mesurées
4.1.1.5 Résultats
4.1.1.6 Discussion de la première étude
4.1.2 Etude 2
4.1.2.1 Participants
4.1.2.2 Matériel
4.1.2.3 Procédure
4.1.2.4 Variables mesurées
4.1.2.5 Résultats
4.1.2.6 Discussion de la seconde étude
4.1.3 Conclusion de la première expérimentation
4.2 H2 et expérimentation 2
4.2.1 L’expérimentation
4.2.1.1 Participants
4.2.1.2 Matériel
4.2.1.3 Procédure
4.2.1.4 Variables mesurées
4.2.2 Résultats
4.2.2.1 Variable de Fluence et d’Originalité
4.2.2.2 Variables Utilité et Faisabilité Technique
4.2.2.3 Catégorisation des résultats
4.2.2.4 Évaluation subjective
4.2.3 Discussion de la seconde expérimentation
4.2.4 Conclusion de la seconde expérimentation
4.3 H2 et expérimentation 3
4.3.1 L’expérimentation
4.3.1.1 Participants
4.3.1.2 Matériel
4.3.1.3 Procédure
4.3.1.4 Variables mesurées
4.3.2 Résultats
4.3.2.1 Variable de Fluence et catégorisation des items
4.3.2.2 Variables Originalité et Utilité
4.3.2.3 Analyse du contenu
4.3.2.4 Evaluation subjectives
4.3.3 Discussion de la troisième expérimentation
4.3.4 Conclusion de la troisième expérimentation
5. Conclusion générale

Rapport PFE, mémoire et thèse PDFTélécharger le rapport complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *