• Aucun résultat trouvé

2. Chapitre 2 : Le besoin

2.2. Approche bibliométrique

2.2.6. Définition dans le domaine de l’informatique

Dans ce paragraphe, nous nous intéresserons à la notion du besoin dans le domaine de l’informatique. Nous avons trouvé au moment de la réalisation de cette étude que la base de données Scopus référence 3786 articles en relation avec le besoin.

2.2.6.1.Définition du besoin

En informatique, et le domaine des nouvelles technologies de communication et d’informations en général, on observe une grande diversité des significations du terme besoin. Nous en avons pris conscience lorsque nous avons assisté à une conférence internationale

(COMPSAC 20084) organisée par l’IEEE Computer Society. L’un des workshops, dans lequel nous avons présenté nos travaux, a traité de la notion de l’ingénierie du besoin pour les services (REFS085). L’identification des besoins est l’une des activités les plus critiques dans le développement des logiciels (Hickey et Davis, 2004). En affinant la recherche dans ce domaine et en examinant les mots clés utilisés dans ces publications, nous pouvons constater que les publications peuvent se subdiviser en deux catégories principales.

Une première catégorie qui s’occupe du besoin dans l’utilisation de l’outil informatique. Dans cette catégorie on retrouve beaucoup plus la notion d’utilisateur et de satisfaction du besoin. Le développement de logiciels étant une activité qui vise à créer un système qui résout les problèmes des utilisateurs et leur donne de nouvelles opportunités, identifier les besoins est crucial pour la réussite du logiciel (Hickey et Davis, 2004). Parmi les mots clés qui sont utilisés dans cette catégorie, on trouve par exemple « Requirements engineering, Specifications, Human Computer Interaction, Customer Satisfaction, Computer software selection and evaluation, User interfaces,… ». Ce sont des mots qui montrent que les publications s’orientent vers la description des tâches des utilisateurs lorsqu’ils font appel à un outil informatique et à la manière de concevoir l’interface Homme-Machine en tenant compte de variables ergonomiques et en recherchant la facilité d’utilisation de l’outil. On retrouve aussi des références à la notion de spécification qui se rapproche de la rédaction du cahier des charges plus qu’à l’analyse de besoin. Enfin la sélection et l’évaluation de logiciels concerne l’évaluation de produits finis ou de concepts plutôt qu’à notre domaine d’étude. C’est ainsi que (Maiden et al., 2008) définissent l’analyse de besoins dans le domaine informatique comme étant un processus créatif dans lequel des acteurs travaillent ensemble pour créer des idées de nouveaux logiciels. Celles-ci étant éventuellement exprimées comme étant des besoins. Donc un besoin est considéré comme une activité créative. Cette approche pose problème en ingénierie de l’innovation où le processus créatif est présent à de nombreuses étapes de la conception.

(Gao et al., 2007) ont montré l’importance de la notion du besoin des utilisateurs dans le processus de développement d’Intel. En effet, Intel a fait le choix stratégique de se transformer d’un fabricant de micro-processeurs à une entreprise qui offre une plateforme de produits, une plateforme étant en informatique un ensemble de produits qu’Intel délivre au marché sous la forme d’une solution intégrée. Ce choix stratégique a fait paraître des difficultés chez Intel dans la traduction des données marketing en produits. Prenons l’exemple du concept de nomadisme (l’utilisation des médias n'importe où, n'importe quand), les ingénieurs d’Intel ont anticipé quelles technologies devaient être utilisées (connaissances scientifiques à valoriser). Mais ce niveau de détail est insuffisant pour les concepteurs pour qu'ils traduisent ces données en produits. De ce fait, Intel a mis en place un modèle permettant d'identifier les besoins par l'usage que les utilisateurs font du produit. Le modèle identifie ainsi une liste de besoins, appelés « cas d’usage » dans le jargon d’Intel (Use case). Les cas

4 32nd Annual IEEE International Computer Software and Applications Conference, Turku, Finland, 28 juillet-1 août, 2008

5 2nd IEEE International Workshop on Requirement Engineering for Services: Understanding the Dynamics of User Needs

d'usage correspondent à une interaction spécifique entre un ou plusieurs acteurs et le système informatique développé. Un ensemble de cas d'usage forment un modèle d'usage (Usage Model, l’équivalent de l’ensemble des besoins). Ainsi, si l’on veut définir le besoin, on doit l’expliquer par rapport aux cas d’usage. Selon cet exemple d’Intel, un besoin est un objet ou un service qui facilite à terme la situation d’usage étudié, en d’autres termes, le besoin correspond à une future fonction.

Une deuxième catégorie des articles en informatique est beaucoup plus reliée au domaine lui-même. Dans cette catégorie les mots clés utilisés sont beaucoup plus techniques. Par exemple, on retrouve des mots tels que « Software engineering, Patterns Engineering,

Mathematical models, Computer simulation, Information technology, Computer

architecture,… ». Dans cette deuxième catégorie, le besoin est considéré comme étant les spécifications du produit ou de l’outil informatique. En effet, l’une des traductions possibles de « Requirement » est « spécification », donc les spécifications techniques de l’outil. Le but est de donner une aide aux concepteurs des outils informatiques pour définir les fonctions de leur produit. C’est une vision plus fonctionnelle du besoin et qui s’inscrit selon un point de vue des concepteurs.

2.2.6.2.L’analyse du besoin

Pour (Parviainen et Tihinen, 2007), l’analyse de besoins est un processus dans lequel diverses demandes de produits de la part de différents types d’acteurs doivent être considérées. L’analyse de besoins est alors considérée comme étant l’une des étapes les plus critiques et complexes du développement informatique et plus particulièrement des systèmes embarqués. Traditionnellement, cette étape est réalisée au début du processus. Avec les changements fréquents des besoins des utilisateurs, il est recommandé de faire des analyses de besoins de manière itérative et régulière tout au long du processus (Hickey et Davis, 2004). Nous avons vu qu’Intel utilise un modèle pour définir les besoins par l'usage. En fait une démarche complète en amont des projets est mise en œuvre (processus appelé Cycle de vie des plateformes-produits). Reprenons l’exemple de l'utilisation nomade des outils multimédia. Il contient plusieurs cas d'usage tels que : l'utilisateur choisit et classe de la musique du PC vers d'autres équipements dans la maison ou il construit des listes de diffusion à partir de n'importe quel équipement vers le réseau domestique... Le modèle d’usage et ses cas d’usage ainsi déterminés font l’objet d’études approfondies menées pour mieux comprendre les comportements des utilisateurs dans le contexte du produit. Ceci sert à la validation des cas d’usage. Ce travail de validation est obtenu par le biais de différentes méthodes combinant des facteurs humains et des méthodologies de conception (interrogations, entretiens semi-directes, tests avec prototypes…). Nous en déduisons que les études d’analyse de besoins sont plus performantes si elles utilisent une combinaison d’outils de différentes natures méthodologiques (quantitatives, qualitatives, collectes d’informations, études techniques…). Suite à cela, vient une étape très importante dans l’analyse de besoins selon le modèle d’Intel, qui est sa formulation. Pour cela, il est recommandé que les besoins soient formulés de manière complète, correcte, claire, concise, consistante, cohérente, plausible, avec une priorité et vérifiable. Exemple de formulation :

Nom : Affichage secondaire d’état d’enregistrement

Description : L’ordinateur doit afficher l’état d’enregistrement quand l’ordinateur est en cours d’enregistrement d’un programme télé ou en capture d’un contenu numérique, même si l’écran est éteint.

Objectif : Les appareils d’enregistrement de programmes télé affichent généralement un voyant montrant l’état de l’enregistrement, permettant à l’utilisateur de voir la progression sans mettre en marche l’écran.

Priorité : Elevée, essentiel pour une offre compétitive

Les besoins sont ainsi exprimés dans un langage facilement compréhensible par les architectes systèmes ou les programmeurs informatiques. La description est à la fois fonctionnelle (ce que fera l’appareil innovant) et elle traduit des défauts des engins actuels.

Une démarche d’analyse de besoins est constituée de manière générale des étapes suivantes (Hickey et Davis, 2004) :

- Identification : apprentissage, découverte, extraction des besoins des clients, utilisateurs et autres acteurs principaux

- Analyse : analyse des informations extraites pour générer une liste de besoin. Des modèles d’analyses doivent être utilisés dans le but d’accroitre la compréhension des besoins

- Tri : détermination d’un sous-ensemble de besoins à inclure dans le futur logiciel - Spécification : Description du comportement visible et extérieur du logiciel

- Vérification : détermination de la consistance, la cohérence et l’exhaustivité ainsi que le manque et les défauts des besoins

Notons qu’on retrouve dans la bibliographie du domaine informatique, différentes approches utilisant d’autres terminologies pour désigner ces étapes. Par exemple : analyse des problèmes et description des produits ; identification des besoins et analyse des besoins ; identification, expression et validation ; identification, négociation, spécification et validation/vérification ; identification, analyse, spécification, vérification et management. La majorité des modèles présentent leurs étapes de manière séquentielle. En réalité, elles doivent être réalisées de manière itérative et concourante. Face à cette multiplicité de modèle, (Hickey et Davis, 2004) ont proposé un méta-modèle (modèle unifié pour l’identification des besoins) permettant de bien choisir le modèle d’identification des besoins. Le choix se base sur le problème, la solution et les caractéristiques du domaine du projet informatique.

2.2.6.3.Synthèse

Dans ce paragraphe, nous avons exploré la notion de besoin dans le domaine de l’informatique. Nous avons vu que le besoin peut être relié à deux usages différents : pour désigner l’usage de l’outil informatique, d’un coté, et les spécifications techniques d’un autre coté.

Nous avons vu également que selon (Maiden et al., 2008), le besoin est associé à un processus créatif.

En informatique, selon Maiden et al. (2008), le besoin est associé à un processus créatif. Nous considérerons plutôt qu’analyser des besoins est une source d’idées et que l’on peut intégrer l’analyse de besoins dans un processus créatif.

Mais l’analyse de besoins peut aussi jouer un rôle en évaluation (exemple d’Intel)

Nous avons aussi compris la notion de besoin à travers l’exemple d’Intel.

Le besoin peut être défini par rapport aux usages que l’ont fait du produit. Le besoin correspond alors à une future fonction.

Comme pour les autres domaines scientifiques que nous avons explorés, nous avons retrouvé l’aspect multi-acteurs du besoin et des démarches d’analyse de besoin.

Par ailleurs, ces démarches peuvent être de plusieurs natures, comme nous l’avons également compris à travers les autres domaines scientifiques. Le mieux est de combiner plusieurs types d’outils

Pour une meilleure performance et une meilleure exhaustivité, les études d’analyse de besoins doivent comporter plusieurs outils méthodologiques (interrogations, entretiens semi-directs, tests avec prototypes…). Nous en déduisons que les études d’analyse de besoins sont plus performantes si elles utilisent une combinaison méthodologique (quantitatives, qualitatives, collectes d’informations, études techniques…).

Enfin, la formulation du besoin est l’une des étapes clé dans une démarche d’analyse. C’est pour cela qu’il faut veiller à ce que chaque besoin soit bien explicité.

Il est recommandé que les besoins soient formulés de manière complète, correcte, claire, concise, consistante, cohérente, plausible, avec une priorité vérifiable.