Interaction homme-

machine(IHM)
Cours 5: CONCEPTION DES IHM
 Introduction
• Phases du cycle de développement d’un logiciel :

Analyse/Spécification (analyse de l’existant,

spécifications fonctionnelles et non fonctionnelles)

Conception

Réalisation (programmation, tests)

• Après le développement :

Livraison/ utilisation

Maintenance (mises à jour, correction de bugs)

 Introduction
• IHM d’une application :

Artefact concret qui sera utilisé par les utilisateurs

Un tiers des questions lors de réunions avec les utilisateurs porte sur
les IHM

Phase de maintenance :

‣ 33% de debugging

‣ et 67% de changements demandés par les utilisateurs

Exemples de mauvaises IHM
• Accident nucléaire de Three Mile Island (1979) :

• Les causes :

panne d’une pompe à eau à un problème du générateur de vapeur et

donc du refroidissementàLa turbine puis le réacteur s’arrêtent alors.
(Panne matérielle)

augmentation de pression à un technicien ouvre une vanne pour éviter

une surpression dangereuseàMais la fermeture automatique ne se
produit pas. (erreur humaine)

aucun signal ne l’indique. (Mauvaise IHM)

fuite du liquide de refroidissement à nouvelle surchauffe et production

d’une multiplicité de signaux confus. (Mauvaise IHM/contrôle d’erreurs
non prévues)
Exemples de mauvaises IHM

• Catastrophe de l’Airbus (1992) : confusion d’affichage des

unités sur un cadran d’altimétrie.
Méthodes du génie logiciel
1. Quick and dirty
2. Modèles linéaires
• Modèle en cascade
• Modèle en V
3. Modèles itératifs
• Modèle par incréments
• Modèle en spirale
4. Merise
5. Méthodes agiles
Quick and dirty/ ad-hoc
• Initialement le nom du système d’exploitation MSDOS était
QDOS, pour Quick and Dirty OS

• Pas de description précise des étapes:

Phase d’analyse et de conception souvent limitée (voire
inexistante)
Programmation rapide mais sale, code peu réutilisable
Encore utilisée pour des prototypes, maquettes ou projets
d’étudiant-e-s...

àMéthode à éviter
 Modèles linéaires:
Modèle ou CV en cascade
• Il est hérité de l'industrie du BTP (Bâtiment et travaux
publics) (1966).

• Les phases traditionnelles de développement sont

effectuées simplement les unes après les autres, avec un
retour sur les précédentes.

• Le passage à la phase suivante ne se fait qu’après une

étape de validation-vérification.
èLes étapes du modèle sont génériques

èPréférable à un développement aléatoire (ad hoc)

 Modèles linéaires:
Modèle ou CV en cascade
 Modèles linéaires:
Modèle ou CV en cascade: inconvénients

• Modèle trop séquentiel : ce n’est pas le cas des projets réels.

• Retour uniquement sur la phase précédente :remise en

question coûteuse des phases précédentes

• Effet tunnel : Validation tardive/obtention tardive d’une

version exécutable

• Sensibilité à l'arrivée de nouvelles exigences : refaire toutes

les étapes?

• Difficulté de définir les besoins de façon exhaustive dés le

début (particulièrement vrai pour les IHM).
 Modèles linéaires:
Modèle ou CV en V

• Modèle très populaire (1980) :

• Développement et tests effectués en parallèle :

préparation préalable des tests

• Importance des documents (livrables)

• Retours possibles à chaque étape

àTient d'avantage compte de la réalité.
Modèles linéaires:
Modèle ou CV en V
 Modèles linéaires:
Modèle ou CV en V: inconvénients

• Difficulté de prise en compte des changements

importants dans les spécifications dans une phase
avancée du projet

• durée parfois trop longue pour produits compétitifs

• pas de gestion du risque : trop de choses reportées à

l'étape de programmation (comme les IHM)

• pas assez de bornes intermédiaires pour valider la version

finale du produit.
 Modèles itératifs:
Modèle par incréments
• Années 80

• Construction du noyau

• Ajout progressif de fonctionnalités.

 Modèles itératifs:
Modèle par incréments

• Chaque incrément peut donner lieu à un cycle de vie

• Différent de la décomposition du système en sous-

systèmes intégrés à la fin.

• Possibilité de livraisons et de mise en service après

chaque incrément.
 Modèles itératifs:
Modèle par incréments: inconvénients

• Risques:

de mise en cause du noyau ou des incréments

précédents

de ne pas pouvoir intégrer de nouveaux incréments

 Modèles itératifs:
Modèle en spirale
• Meta-modèle défini en 1986 par Barry Boehm :

• Itérations longues (6 mois à 2 ans)

• Chaque cycle est découpé en 4 phases

Déterminer les objectifs, les alternatives pour les atteindre et les

contraintes

Évaluation des alternatives (prototypage, simulation...), analyse des

risques (défaillance du personnel, calendrier ou budgets irréalistes,
risques technologiques, IHM inappropriées …)

Développement, validation et vérification de la solution retenue (en

utilisant un autre modèle de CV)

Planification du cycle suivant

Modèles itératifs:
Modèle en spirale
 Modèles itératifs:
Modèle en spirale: inconvénients
• Étape d’analyse de risques que l’utilisateur doit accepter
car :
Coût important de l’analyse des risques
Expertise requise
àCV à utiliser pour les grands projets et les missions
critiques
 MERISE

• Méthode française pour l’analyse, la conception et la

gestion de projet de systèmes d’information (très
populaire aux années 70 et 80).

• La méthode MERISE préconise d'analyser séparément

données et traitements, à chaque niveau.

• Vérification de la cohérence entre ces deux analyses

avant la validation et le passage au niveau suivant.
MERISE

MCD et MCT

MLD et MLT

MPD et MPT
MERISE: inconvénients
• Cette méthode reste adaptée pour la gestion des projets
internes aux organisations, se limitant à un domaine
précis.

• Elle est en revanche moins adaptée aux projets

transverses aux organisations.

• Inadaptée aux environnements distribuées.

• Séparation entre données et traitements.

 Méthodes agiles :
présentation

• Agile regroupe plusieurs méthodes existantes partageant

des valeurs communes :

• Développement itératif, incrémental et adaptatif

• Forte collaboration interne et externe (avec le client)

• Logiciels opérationnels
Méthodes agiles :
présentation
Méthodes agiles Vs méthodes
classiques
Méthodes agiles Vs méthodes
classiques
Méthodes agiles : Exemples
• Rapid Application Development (RAD, 1991)

• Rational Unified Process (RUP, 1995)

• Dynamic Systems Development Method (DSDM, 1995)

• Scrum (1996)

• Feature Driven Development (FDD, 1999)

• Extreme Programming (XP, 1999)

• Adaptive Software Development (ASD, 2000)

• Crystal Clear (2004)

Méthodes agiles : Exemples/
comparatif
Méthodes agiles : Scrum
• La méthode s'appuie sur le découpage d'un projet en boîtes de temps,
nommés « sprints ».

• Les sprints peuvent durer entre quelques heures et un mois.

• Chaque sprint commence par une vérification de la planification

opérationnelle.

• Le sprint se termine par une démonstration de ce qui a été achevé.

• Avant de démarrer un nouveau sprint, l'équipe réalise une rétrospective :

elle analyse ce qui s'est passé durant ce sprint, afin de s'améliorer pour le
prochain.

• L'adaptation et la réactivité de l'équipe de développement est facilitée par

son auto-organisation..
Méthodes agiles : Scrum
Méthodes agiles : Scrum
Méthodes agiles : Bilan
Accroissement de la productivité

Produire la plus grande valeur métier dans la durée la plus courte

(Réduction du « time-to-market »)

Avantages compétitifs liés à la réactivité au changement.

Amélioration forte de la qualité.

Economie par réduction des déperditions de ressources.

Satisfaction du client

Motivation de l’équipe
Méthodes agiles : Bilan

Temps et coût inconnus en début de projet

Favorise le code jetable

Difficile de faire participer le client

Méthodes du GL et IHM
Méthodes du GL et IHM

Les méthodes Agile poussent à impliquer fortement les

utilisateurs pendant la phase de conception du logiciel.
Méthodes du GL et IHM
Utilisateur impliqué principalement en aval et en amont du projet
(analyse et évaluation)
Plutôt orientées système (techno-centrées)
Ne répondent pas à des questions comme :

• «Toutes les zones de l’écran sont-elles pertinentes pour l’utilisateur

• Quels critères nous permettent de préférer les menus aux

boutons ?»

• Et d’autres questions ergonomiques

àInsuffisantes pour la prise en compte de l’utilisateur et de
l’ergonomie
Méthodes du GL et IHM
• L’expérience montre en IHM que l’on doit :

travailler de manière itérative et par des

raffinements successifs.

prévoir lʼusage en même temps que les fonctionnalités,

contrairement au méthodes du GL où il y a
indépendance entre le noyau fonctionnel et lʼinterface
utilisateur (Interface et interactions ne sont définis
qu’après)

• Existe-t-il des méthodes orientés IHM ?

 Méthodes IHM
1. Conception itérative

2. Conception par prototypage

3. Conception centrée utilisateur

4. Conception participative

5. Conception informative

6. Exemple de CV orienté IHM: CV en étoile

 Conception itérative

• Succession de phases :

Affinements progressifs des spécifications du produit

Évaluations des solutions retenues

Réalisations, modifications jusqu’à obtention d’un

produit satisfaisant
 Conception itérative
• Le processus de construction est itératif :

Pour des problèmes difficiles à spécifier

Processus de conception ni ascendant, ni descendant

Développement de solutions partielles, intermédiaires

Apparition en cours de développement de nouveaux objectifs

Prise en compte de l’avis des utilisateurs qui peuvent changer

Communication au sein de l’équipe de conception, avec les utilisateurs

Difficulté à gérer la conception itérativeàprototypage

 Prototypage
• Le prototypage permet :

• Aux concepteurs de travailler sur plusieurs ensembles de

détails à la fois

• Aux utilisateurs de voir ce que sera le système final

• De se concentrer sur les parties problématiques de

l’interface

• D’étudier des alternatives de conception

• De s’assurer de l’utilisabilité du système

 Prototypage
• Types de prototype :

Prototypes informels, sur papier

Prototypes vidéo

Prototypes informatiques

http://www.agile-ux.com/2011/02/22/
agile-prototyping-tools-paper-
whiteboard-and-balsamiq/
 Prototypage : prototype
informel
• Dessiner des écrans sur papier, sur logiciel

• Utiliser des post-its / transparents / présentations pour des

montages dynamiques

• Exécuter un scénario et essayer des variantes pour des choix

de haut niveau : décider des fonctionnalités qui seront

disponibles

de niveau intermédiaire : dessiner une séquence d’écrans

de bas niveau : dessiner des idées d’icônes

Prototypage: prototype vidéo

• Créer une vidéo de l’utilisation d’un prototype

• Simuler les fonctionnalités non implantées, les

interactions
 Prototypage : prototype
informatique

• A l’aide d’outils :

Visual Basic, Delphi, Visual C, Tcl-Tk, Pencil

Conception centrée utilisateur
(CCU)

• Conception à 3 phases:

1) analyse

2) conception

3) évaluation et mise en œuvre

Conception centrée utilisateur
(CCU)
• Prise en compte des utilisateurs
Dès la phase dʼanalyse

Etude de lʼutilisateur et de sa tâche

• Nécessite de spécifier les caractéristiques

De lʼutilisateur

De la tâche à réaliser
De lʼinteraction

• Relations concepteur – utilisateur

Utilisateur interrogé sur ses attentes
Questionné sur le logiciel conçu
 CCU: Analyse

• Cette étape débute par une analyse des systèmes

existants et concurrents,

• ensuite la définition de la population ciblée (modèle de

l’utilisateur )

• et du contexte d’utilisation (modèle de la tâche).

CCU: Modèle de l’utilisateur
• Objectifs :
Identifier les caractéristiques pertinentes des utilisateurs
Réduire les distances d'exécution et d’interprétation

• Pour cela :
Parler aux utilisateurs n'est pas un luxe, c'est une
nécessité
Il faut se concentrer sur l'utilisateur le plus tôt possible et
de façon continue
Il faut faire participer l'utilisateur à la conception
CCU: Modèle de l’utilisateur

• Données générales

niveau de formation, habitudes culturelles

taille, âge, sexe, déficiences

• Données liées à l’application : compétences sur le

domaine/en informatique

débutant, occasionnel, expérimenté, expert

CCU: Modèle de l’utilisateur

• Problèmes :
Choix des utilisateurs représentatifs

Accès aux utilisateurs

Omission du contexte d’utilisation

• Techniques :
Classification générale si utilisateur non disponible

Techniques de recueil d’informations

CCU: Modèle de la tâche

• Tâche : But + Procédure pour l’atteindre

• Procédure : ensemble de sous-tâches liées par des

relations de composition et des relations temporelles

• Tâche élémentaire : tâche décomposable en actions

physiques (opération d'E/S)
CCU: Modèle de la tâche
• Résultats attendus :

Construire la hiérarchie de tâches (jusqu’aux élémentaires)

Identifier les variables psychologiques

Spécifier chaque tâche : préconditions, postconditions, fréquence,

complexité, criticité, acteur responsable (utilisateur ou système) …

• Méthodes :
Observation directe en laboratoire ou sur le terrain

Entretien

Groupe de travail : rassembler utilisateurs et concepteurs

(brainstorming, scénario)
CCU: Modèle de la tâche

Exemple : modèle de la tâche « envoyer un SMS »

 CCU: Conception

• respect des principes ergonomiques

• construction de la structure des menus et découpage en

fenêtres / pages Web

• Guide lʼimplémentation des fonctionnalités précises

 CCU: Evaluation

• Validation des choix de conception et dʼimplémentation

par des tests dʼusage sur prototypes
 CCU: Bilan
• Avantages
Prise en compte de lʼutilisateur avant la phase dʼévaluation

• Difficultés
Choisir des utilisateurs représentatifs et disponibles

Ne pas oublier le contexte réel dʼutilisation

Expliciter les comportements, les connaissances mises en jeu…

• Techniques de recueil dʼinformation auprès des utilisateurs

Observation directe, entretiens, questionnaires
Conception participative
• Prise en compte des utilisateurs :
Pas seulement comme testeurs
Mais aussi comme partenaires de conception :
Tâches essentiellement connues des utilisateurs
Source possible d’innovations

• Relations concepteur-utilisateur :
Utilisateur partenaire de conception à part entière
Et participe aux choix de conception finaux
 Conception participative:
Bilan
• Avantages
Seuls les utilisateurs connaissent la réalité des tâches (surtout celles mal
identifiées ou peu structurées)
Facilite l’acceptation du logiciel

• Difficultés
Augmentation des coûts de développement
Contradictions possibles entre les utilisateurs
Obligation d’accepter des compromis pour satisfaire des participants,
même s’ils ont tort

• Techniques de recueil d’informations associées

Scénarios, magicien d’Oz, inspections cognitives, brainstorming,
prototypes
Conception informative
• Prise en compte des utilisateurs :
Pas seulement comme testeurs

Mais sans les considérer comme partenaires de conception

Méthode imaginée pour la conception avec des enfants

• Relations concepteur-utilisateur :
Utilisateur dans l’équipe de conception

Mais ne participe pas aux choix finaux

Conception informative : Bilan
• Avantages
Prendre l’avis de l’utilisateur
Eviter les contradictions possibles entre les utilisateurs
Pas d’obligation d’accepter des compromis pour satisfaire des
participants, même s’ils ont tort

• Difficultés
Augmentation des coûts de développement

• Techniques de recueil d’informations associées

Scénarios, magicien d’Oz, inspections cognitives, brainstorming,
prototypes
 Cycle de vie en étoile
• Exemple de cycle de vie basé ergonomie (ou IHM)

• Par une équipe de spécialistes d’IHM

• centré sur l’utilisateur et sur l’évaluation.

• itératif et à raffinements successifs

• après chaque phase d’étudeàévaluer l’utilisabilité

• l’évaluation n’est pas une étape séparée de la conception

mais "un état d’esprit", c’est une préoccupation
complètement intégrée à la conception (Kolski).
Cycle de vie en étoile
 Méthodes IHM: Bilan
• Garder les points forts des différentes méthodes :
Prise en compte précoce de l’utilisateur
Prise en compte précoce de l’évaluation

• Centrées utilisateuràComment recueillir des informations ?

 Technique de recueil
d’information
1. Scénarios de conception

2. Inspections cognitives (cognitive walkthroughs)

3. Magicien dʼoz

4. Entretiens / Enquêtes

5. Observations

6. Questionnaires

7. Remue-méninges (brainstorming)

8. Audit ergonomique
Scénarios de conception
• But :

Créer une description réaliste de l’utilisation du

nouveau système

• Moyen :

Utiliser les scénarimages (storyboards) du monde

du cinéma

Points clés, commentaires, enchaînements

Pour une vue d’ensemble de l’interaction

Scénarios de conception
• Procédure :

Identifier des activités existantes

Typiques

Inhabituelles

Créer des scénarios de travail en généralisant les histoires

mélanger les événements de différentes provenances

incorporer des situations inhabituelles dans des activités

typiques

inclure des situations qui aboutissent et d’autres pas

Scénarios de conception

Exemple: Scénario avec commentaires - enchainements

Scénarios de conception

Exemple de scénarimage
 Inspections cognitives
• But :
Évaluer le système en se mettant à la place de l’utilisateur

• Moyen :
Spécification d’une série de tâches et des séquences
d’actions pour les réaliser

• Procédure :
Évaluation en imaginant ce que ferait l’utilisateur
comprend-il les messages, le comportement du système ?
Interprétation et prise en compte des résultats
 Magicien d’Oz
• But :
Simuler les fonctionnalités absentes du système
Système réel inexistant ou partiellement développé
Technique difficile à mettre en place : adapté à des systèmes lourds,
difficile à développer

• Procédure :
Un compère effectue les actions à la place du système
Le “magicien” interprète les entrées de l’utilisateur
Il supplée aux manques du prototype et contrôle le comportement du
système
Sensation d’utiliser un vrai système
 Magicien d’Oz

• Exemple :
projet DIALORS, un système de dialogue pour réserver
un billet de train en langage naturel
Expérimentations réelles en 1984 : une opératrice
simule les réponses du système

• L De moins en moins utilisé à cause des logiciels de

prototypage d’interface
 Enquête / entretien
• But :
Identifier des pistes de conception pour les prochaines
itérations ou des exemples spécifiques de problèmes
rencontrés par les utilisateurs

• Caractéristiques :
Interviewer l’utilisateur dans son environnement de travail
(face à face)
Durée recommandée de 45 minutes / une heure
Privilégier le magnétophone à la prise de notes (traces et
concentration sur l’échange)
 Enquête / entretien
• Procédure :
Rassembler un panel représentatif d’utilisateurs
Pendant l’interview en face à face
questions semi-directives pour l’analyse (degré de liberté)
questions plutôt directives pour l’évaluation (cibler un
élément)
neutralité de l’enquêteur
reformulation des réponses
Analyse des résultats
 Enquête / entretien

• Possibilité d’utiliser les entretiens pour des incidents

critiques :
Détecter les points forts et points faibles d’un système
Demander de se souvenir d’un problème particulier
vécu dans un passé récent
Demander de décrire chaque incident en détail
Demander ce qui est habituel et ce qui ne l’est pas
dans l’incident
Enquête / entretien: Bilan

• Avantages
Analyse qualitative
Identification des tendances et des priorités, ou dans le
cas d’entretiens critiques, des points forts (à renforcer)
et des points faibles (à corriger)

• Inconvénients
Vision subjective (ne pas en tirer des conclusions
chiffrées)
 Observations
• But : Identifier les gros problèmes du logiciel (prototype / système final)

• Procédure :
En laboratoire ou sur le terrain
Définir une mission spécifique (résoudre un problème, suivre un
scénario)
Choisir au moins 2 utilisateurs qui agiront indépendamment, leur
demander d’effectuer la tâche :
observation directe simple
avec explication à haute voix
à deux pour observer leurs interactions (interrogations,
explications)
 Observations
• Procédure : (Suite)

Enregistrer les interactions, puis les analyser

Papier àJ coût acceptable

audio, vidéo àJ voir le visage, la posture de l’utilisateur, voir l’écran Lcoûteux

trace informatique àJ mémorisation des actions de l’utilisateur, permet de

rejouer la session
 Questionnaires
• But : Résumer économiquement l’avis de nombreux utilisateurs

• Procédure :

Déterminer le public (représentatif) destinataire du questionnaire

Comment diffuser/récupérer

Comment analyser les résultats (automatiquement/ manuellement)

• Types de questions :
Informations générales

Questions ouvertes, dirigées, QCM, échelle, classements

 Remue-méninges
• But : Générer un grand nombre d’idées créatives

• Procédure :

Réunir un petit groupe avec différents rôles et expertises

Limiter le temps (1h)

Décrire un problème de conception spécifique

 Remue-méninges
• Phase 1 : générer une grande quantités de solutions

faire participer tout le monde,

enregistrer toutes les idées sans les évaluer

• Phase 2 : classer les idées en fonction de leur qualité

chacun annonce les idées qu’il préfère

les idées sont classées par nombre de votes

commencer la conception à partir des idées les mieux classées

ne pas oublier les idées insolites

 Audit ergonomique
• But : Évaluation rapide d’une interface par des experts en
ergonomie

• Procédure :

Dans l’idéal, évaluation par plusieurs experts

indépendants et confrontation de leurs résultats

En pratique, évaluation par un expert en ergonomie et

relecture par un expert du domaine (Cf. cours«
Ergonomie: principes et évaluation », jugements
d’experts)
 Audit ergonomique
• Avantages
Rapidité de l’audit

Pistes pour prioritiser les étapes suivantes de

conception

• Inconvénients
Coût de l’audit

Aucun retour des utilisateurs finaux de l’application

Bilan: Quelle technique choisir ?
 Conclusion
• Les méthodes de conception en génie logiciel sont
insuffisantes pour la conception des IHM

• Conception de l’IHMàprécoce, méthodique, itérative,

expérimentale

• Pas de méthode scientifique analytique pour la conception

des IHM, mais plutôt des méthodes empiriques

• Pas de méthode idéale

à Combiner différentes méthodes de conception IHM

à Leur associer une ou plusieurs techniques de recueil

d’informations
 Source du cours

• https://isammblog.files.wordpress.com/2015/11/
ihm_ch5_conceptionihm_s_b_abdallah.pdf
• Nadia Elouali: Cours Interaction Homme-Machine (IHM)
• https://www.hcibook.com/e3/
• Cours IHM (Master Ingénierie des Médias) ERGONOMIE :
PRINCIPES ET ÉVALUATION