Réconcilier conception d’interfaces et conception

logicielle : vers la ”conception orientée-systèmes”

Stéphane Chatty

To cite this version:

Stéphane Chatty. Réconcilier conception d’interfaces et conception logicielle : vers la ”conception
orientée-systèmes”. ERGO IHM 2012, Conférence Francophone sur l’Ergonomie et l’Interaction
Homme-Machine, Oct 2012, Biarritz, France. �hal-01021493�

HAL Id: hal-01021493

[Link]
Submitted on 21 Jul 2014

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non,
lished or not. The documents may come from émanant des établissements d’enseignement et de
teaching and research institutions in France or recherche français ou étrangers, des laboratoires
abroad, or from public or private research centers. publics ou privés.
 Réconcilier conception d’interfaces et conception logicielle :
vers la « conception orientée-systèmes »
Stéphane Chatty
Université de Toulouse - ENAC
7 avenue Edouard Belin, 31055 Toulouse Cedex, France
chatty@[Link]

RÉSUMÉ Author Keywords: design, specification, model, interface,

Conception d’interfaces et conception logicielle ont des liens object, process, component, system, interaction
complexes, que la conception par objets a échoué à clarifier.
ACM Classification Keywords: H5.2 [Information Inter-
Nous analysons ici ces rapports et proposons une voie pour
faces and presentation] User Interfaces—GUI ; D2.11 [Soft-
les clarifier. L’échec de la conception par objets provient de
ware engineering] Software Architectures.
son lien avec le modèle de programmation par objets, proba-
blement très éloigné de ce qu’imaginait Alan Kay, dans le- General Terms: Design ; Human factors ; Language
quel les échanges entre objets sont stéréotypés et décrivent
mal les interactions observées entre objets physiques, entre INTRODUCTION
humains, et entre humains et appareils numériques. Appli- Grâce à la popularisation du design d’interaction et du « UX
quer ce modèle à l’IHM restreint le pouvoir d’expression des design », le métier de concepteur d’interfaces homme-machine
concepteurs, et tend à opposer des activités de conception qui est désormais reconnu dans la profession informatique. Il n’en
devraient n’en constituer qu’une. En s’appuyant sur le modèle a pas toujours été ainsi, et la conception d’interfaces elle-
de programmation par composants interactifs, appuyé sur un même a parfois été mise en cause en tant qu’activité de concep-
modèle théorique de processus en interaction, il devient envi- tion. Historiquement, en matière de logiciel ce terme était ré-
sageable de disposer d’un ensemble commun de concepts de servé à la définition de la structure des programmes afin de
base. Dans ce cadre, concevoir revient à analyser, modéliser répondre à une spécification 1 , activité qui a donné naissance
ou définir des systèmes et leurs interactions, et spécifier re- au génie logiciel. La conception d’interfaces est née des be-
vient à imposer des contraintes aux systèmes restant à conce- soins que ce domaine ne couvre pas, d’abord sous forme de
voir. Conception logicielle et conception d’interfaces peuvent réglages finaux (couleurs et paramètres divers), puis progres-
alors reposer sur un socle commun de méthodes et d’outils, sivement comme une étape préalable à la spécification.
tout en définissant des interactions entre systèmes de nature
C’est ainsi qu’ont émergé deux tâches et deux communautés
différentes : entre composants logiciels d’une part, entre lo-
de conception, chacune protégée des problèmes et des mé-
giciel et système cognitif et perceptif d’autre part. Cela ouvre
thodes de l’autre par un document de spécification. Hélas,
aussi la voie à la conception de systèmes homme-machine
comme le souligne la difficulté à définir un format de spé-
plus complexes, intégrant procédures, formation et interac-
cification qui convienne à tous, cette organisation du travail
tion entre humains, ainsi qu’à de nouvelles approches du par-
n’est pas optimale. Tant que l’espace de conception est étroit,
tage de responsabilités entre humain et automatisme.
il est possible de trouver une organisation et un langage de
spécification qui fonctionnent. Mais dès qu’il s’agit de sys-
ABSTRACT tème complexe ou d’interaction riche, il est difficile de défi-
Object-oriented design has failed to avoid a rift between inter- nir une organisation efficace, tant les choix effectués de part
face design and software design, because the messages used et d’autre deviennent interdépendants. La « conception du lo-
in object-oriented poorly describe the interactions between giciel » que Winograd appelait de ses voeux [21] reste un ob-
between users and their environment. By relying on process jectif à atteindre en tant qu’activité intégrée et organisée.
theories and interactive component programming, one can pro-
pose a common language between designers : that of system- Cet article esquisse un socle conceptuel unifié, afin de contri-
oriented design, in which they all describe interfaces between buer à l’harmonisation des processus d’ingénierie des sys-
systems and design new systems. tèmes homme-machine. J’y constate d’abord qu’il n’y a pas
deux, mais plusieurs métiers de conception. Je distingue en-
suite les aspects organisationnels, qui reposent sur des fron-
tières entre rôles, et la nature des concepts manipulés, qui
c ACM, 2012. This is the author’s version of the work. It is posted here doivent reposer sur des bases communes. J’analyse alors en
by permission of ACM for your personal use. Not for redistribution. The quoi les méthodes de conception par objets ont échoué à pro-
definitive version was published in Ergo’IHM 2012, October 16–19, 2012, poser des concepts utilisables par tous. Je propose, en m’ap-
Biarritz, France. [Link] puyant sur des recherches en modélisation des systèmes in-
1. qui n’est pas une expression de besoins, voir ISO/IEC 2382-20

1
teractifs, d’utiliser le concept de système comme base com- Mais ce schéma peine à masquer les problèmes. C’est vrai en
mune à toutes les activités de conception. Cette proposition termes temporels d’abord ; il est souvent nécessaire d’itérer
est illustrée par des exemples d’utilisation du concept de sys- pendant le développement du logiciel, c’est d’ailleurs l’ob-
tème comme support à la description de solutions, voire à la jet de RUP et des méthodes de développement agiles [7].
résolution de problèmes, dans diverses phases de conception. Mais alors, à quoi devrait ressembler le schéma et comment
développeurs et concepteurs d’IHM doivent-ils travailler en-
CONCEPTION D’INTERFACES, CONCEPTION LOGICIELLE semble ? De même, pour les grands projets il est souvent im-
Histoire d’un divorce à l’amiable pensable de concevoir totalement l’IHM avant de débuter le
Quand a été la dernière fois qu’un spécialiste en génie logi- développement, et les deux activités doivent être paralléli-
ciel s’est exclamé « mais enfin, la conception c’est ce qui suit sables. C’est vrai en termes de contenu ensuite ; pourquoi tout
la spécification, pas ce qui la précède ! » ? Car en effet, se- ce qui relève de l’IHM devrait-il être itératif, et tout ce qui est
lon les canons du génie logiciel, la conception générale et la logiciel traité par un cycle en V ? C’est vrai enfin en termes
conception détaillée suivent la spécification. C’est sur ce mal- de risque ; la clé de voûte du schéma est la spécification, alors
entendu, qui mène à croire que la spécification est systéma- même que tous sont à la recherche de solutions complémen-
tiquement la première étape d’un projet informatique, que se taires : storyboards ou maquettes dynamiques par exemple.
sont construits de nombreux échecs industriels depuis la gé-
néralisation des interfaces graphiques dans les années 1990. La situation n’est donc pas complètement satisfaisante, ce qui
Cela a débuté lorsque des ingénieurs n’ont pas vu que lister se traduit en coûts et en risques dans les projets d’ingénierie
des fonctionnalités ne constituait plus une spécification suf- de systèmes interactifs. Le divorce est-il temporaire, ou tout
fisante pour que des informaticiens produisent le système es- au moins est-il possible de redéfinir les termes de la cohabi-
péré. Cela a continué lorsque certains ingénieurs, pour réagir tation ? C’est l’objet de la suite de cet article, en commençant
aux échecs croissants, ont confié le travail de spécification à par distinguer deux axes dans le découpage entre les activités.
des ergonomes en espérant que ces derniers sauraient imposer
les bonnes contraintes aux informaticiens. Las, les méthodes Qui conçoit quoi ?
du génie logiciel ne produisent pas plus de programmes utili- Depuis le début de cet article, plusieurs expressions ont été as-
sables à partir d’exigences d’utilisabilité qu’à partir de listes sociées au mot « conception » : logiciel, produit, interface, in-
de fonctionnalités. C’est ainsi que de nombreux ergonomes teraction, IHM, système homme-machine, « user experience ».
se sont retrouvés face au défi de la conception, alors qu’ils Toutes sont employées dans des contextes différents, mais il
étaient plutôt préparés à l’analyse de besoin, la formulation est difficile de clarifier leurs différences. A titre d’exemple,
de critères de qualité et l’évaluation. La suite est connue : concevoir une interaction est-il totalement distinct de conce-
la conception d’interfaces est devenue une activité voire un voir du code ? En apparence, sans doute ; mais dès qu’on pro-
métier à part entière, où se retrouvent ergonomes, ingénieurs, duit une description concrète d’une interaction, sous forme
designers, et parfois même informaticiens. d’états et de transitions par exemple, ce qu’on obtient est un
programme. Ce dernier est exprimé dans un langage inhabi-
Le schéma ci-dessous, imaginé par l’auteur en 1994 et utilisé tuel pour un ordinateur, mais il suffit de le traduire pour le
avec succès dans des projets industriels [19], résume la situa- rendre exécutable ; c’est d’ailleurs l’une des bases de l’ingé-
tion résultante : une phase itérative pour la conception d’in- nierie dirigée par les modèles [4]. Prenons un second exemple :
terfaces, suivie d’un cycle en V pour la conception logicielle. les cabinets de design conçoivent des véhicules, des meubles
Il a le mérite de définir une frontière rassurante pour tous, tant et maintenant des logiciels interactifs. Ils ont le même rôle
en termes de compétences qu’en termes d’organisation et de dans tous les cas, et il est tentant de parler de conception de lo-
responsabilités : les uns peuvent s’exonérer des risques liés giciel comme on parle de conception de mobilier. Mais alors
au développement et des détails informatiques sans intérêt, on en est réduit aux subtilités grammaticales pour maintenir la
les autres peuvent travailler dans un cadre industriel rassurant distinction avec le génie logiciel : conception de logiciel d’un
et éviter la fréquentation des utilisateurs, et tous peuvent se côté, conception logicielle de l’autre. Un troisième exemple
retrancher derrière les ambiguïtés de la spécification. est le travail des designers graphiques : de plus en plus, leur
conception visuelle est faite en amont lors de la phase itéra-
tive, mais réutilisée directement dans le logiciel final. Ont-ils
conçu du logiciel ou de l’interface ?

Cette confusion dans le vocabulaire est le reflet d’une réalité

sous-jacente : s’ils interviennent sur des parties différentes,
avec des compétences et des méthodes différentes, à des ni-
veaux de granularité, de précision ou d’abstraction différents,
c’est le même artefact que tous contribuent à définir. Il est
donc logique que leurs productions interagissent, voire que
les frontières varient selon les projets. Mais cette réalité est
brouillée par la diversité des concepts utilisés : tâche, activité,
processus cognitif pour les uns, interaction pour les autres,
formes et contraste pour d’autres encore, fonctions, classes et
patrons pour les derniers. Sans langage commun, il est diffi-
F IGURE 1 : Le cycle « en escargot », combinant spirale et V cile de discerner comment fonctionne la collaboration.

2
Qui conçoit, qui spécifie ? Cette définition rend compte de la variabilité des situations.
Notons d’abord que si le vocabulaire du génie logiciel in- La spécification est un contrat et selon les équipes, les en-
duit une distinction entre ceux qui rédigent une spécification jeux et les relations contractuelles [17], la spécification sera
et ceux qui doivent la respecter, les rôles et les métiers sont macroscopique ou fine, abstraite ou concrète, exprimée sous
plus nombreux : architectes, programmeurs, ergonomes, desi- forme de fonctions ou d’« ilities », fixant des choix d’inter-
gners, etc. Ces rôles sont rarement cantonnés à l’un des deux action et de couleur ou d’architecture logicielle et d’idiomes
camps : les programmeurs peuvent être amenés à spécifier des de programmation. Dans tous les cas il s’agira compléter la
choix techniques, les designers peuvent participer au déve- conception déjà capturée dans cette spécification. Le cas du
loppement du logiciel. La spécification est donc une frontière calcul (conception initiale triviale) ou du « cycle en escargot »
moins structurante qu’il n’y paraît au premier abord. (conception de l’IHM en amont, de l’architecture en aval) en
sont des cas particuliers simples, et il n’existe à ce jour pas de
Pour tenter de comprendre cette frontière, revenons à l’ori- schéma général.
gine du génie logiciel. Pourquoi a-t-il été possible d’affirmer
Vers un langage pour l’interaction entre concepts
que la spécification était la première étape du processus de
conception d’un logiciel ? La spécification étant de toute évi- Derrière la complexité des notions de conception et la spéci-
dence le résultat d’un travail intellectuel, il est cohérent de dé- fication se cachent donc deux réalités :
finir la conception comme un processus d’analyse et de choix – divers métiers produisent des éléments de conception du
et la spécification comme le résultat d’une conception initiale. système interactif, différents dans leur nature et leur niveau
La question devient alors : pourquoi a-t-on considéré comme d’abstraction, mais ayant vocation à interagir entre eux ;
triviale cette conception initiale ? Je propose de l’expliquer – les schémas d’organisation entre ces tâches de conception
par la complexité et la nature des logiciels concernés. Pour sont fluctuants, un métier devant s’adapter aux choix des
un logiciel de calcul, on peut définir ce que l’on attend sans autres ou l’inverse selon les projets.
recourir à une analyse du besoin : c’est le résultat du calcul. Par analogie avec les approches d’ingénierie dirigée par les
Cela explique pourquoi il faut aujourd’hui enrichir les spé- modèles, on peut ainsi analyser le travail collectif comme une
cifications par des maquettes dynamiques : les informations série d’enrichissements successifs des choix de conception,
à transmettre sont plus nombreuses et complexes dans le cas entrecoupés de traductions de ces choix vers un langage com-
d’un système interactif, et même la notation UML et ses dé- préhensible par les autres métiers. Plus les langages sont com-
rivées [3] ne suffisent pas à les capturer de manière humaine- patibles et moindres sont les pertes lors de ces traductions, par
ment acceptable. En dehors du cas trivial du calcul, la spéci- exemple dans la rédaction et la lecture de la spécification. Il
fication constitue une étape entre activités de conception. ne s’agit pas de produire un langage unique utilisé par tous,
car chaque métier a ses propres concepts à manipuler. Mais
Il y a plusieurs frontières candidates entre ces activités : disposer d’une base de concepts communs dont dérivent les
concepts propres à chacun permettrait de diminuer les pertes
– entre le quoi et le comment ; lors des traductions, voire d’établir directement des interac-
– entre l’intérieur (le système à produire) et l’extérieur (son tions entre les productions, par exemple :
environnement), l’interface homme-machine étant un cas – la combinaison d’une interaction tactile avec un style vi-
particulier de cette frontière ; suel, de même qu’on peut combiner un algorithme de tri
– entre ce qui a déjà été décidé, et ce qui reste à décider. avec une structure de données ;
La première frontière, bien que souvent utilisée pour ensei- – la vérification, qu’il s’agisse de compatibilité entre éléments
gner l’analyse des besoins et la spécification, n’est guère utile d’interaction [1] ou de conformité d’un logiciel avec la
dans le cas des logiciels interactifs. Tout d’abord, elle peut tâche analysée [18] ;
conduire à ignorer des résultats déjà obtenus dans la phase – le raffinement d’un choix de conception. Cela peut être la
amont, par exemple les éléments visuels ; les maquettes dyna- définition du contenu de chaque zone d’une interface gra-
miques servent entre autres à compenser l’étanchéité de cette phique dont la structure a été définie dans la spécification,
frontière. De plus, une interaction gestuelle peut relever du ou la mise en œuvre de principes de conception définis au-
quoi ou du comment selon les projets. Cette ambiguïté est un paravant (exemple : « toute opération de destruction sera
facteur d’échec dans les grands projets, où les rôles du quoi précédée de deux demandes de confirmation »).
et du comment peuvent s’intervertir en fin de projet quand Un tel ensemble de concepts de base a déjà été proposé : celui
les utilisateurs font valoir des exigences. La seconde fron- des langages à objets, popularisé à la même époque que les
tière est plus naturelle, et elle s’applique tant au calcul qu’à interfaces graphiques et qui a donné naissance à la concep-
l’IHM. Cependant l’interface homme-machine n’est pas tou- tion par objets ou « conception orientée objets ». Il remplit
jours totalement définie dans la spécification, en particulier les exigences que nous venons de décrire et certains auteurs
dans les grands projets. Qui plus est, plus un logiciel est in- ont proposé de l’appliquer à la conception de systèmes inter-
teractif et plus la définition de l’extérieur contraint la concep- actifs [8], mais avec un succès mitigé.
tion de l’intérieur ; ce partage réduirait donc la marge de ma-
nœuvre des architectes logiciels. C’est donc la troisième fron- ATOUTS ET LIMITES DES OBJETS
tière qui semble la plus pertinente. Dans ce cadre, la concep- La structuration des logiciels en collections récursives d’ob-
tion consiste à accumuler les choix jusqu’à ce que le produit jets qui communiquent par échange de messages a été pro-
final soit complètement défini, et la spécification est la maté- posée par Alan Kay [14]. La communauté du génie logiciel
rialisation d’une frontière entre la conception déjà effectuée s’en est rapidement emparée comme base d’une méthode de
et celle qui reste à faire, sans préjuger de leur nature. conception logicielle [2], celle de la programmation d’IHM

3
comme base pour ses travaux d’architecture avec notablement – De même, quoi qu’en aient dit les spécialistes du modèle
MVC [12] et les « design patterns » [11], et cette influence à objets, le mécanisme de réification par lequel on peut
s’est étendue jusqu’à la conception d’interfaces. Ce succès transformer une idée, un processus, ou tout autre concept
n’est pas dû au hasard. D’une part, l’objectif de Kay était ex- abstrait en objet ne semble naturel que pour les informati-
plicitement la conception de systèmes interactifs. D’autre part ciens. Ces derniers savent d’ailleurs que tous les objets sont
le modèle est délibérément construit sur des théories cogni- représentés en mémoire de manière abstraite quoi qu’il ar-
tives et des concepts philosophiques de base. Il vise à per- rive. Pour les autres le poids du mot « objet », très ancré
mettre à chacun, du concepteur à l’utilisateur final, de mani- dans la réalité du monde physique, est plus fort que le rai-
puler des concepts qui lui sont naturels pour décrire les entités sonnement proposé. De plus, le mot a déjà un sens particu-
qu’il manipule, et inclut des mécanismes d’abstraction pour lier pour les designers. Cela introduit donc une contrainte
décrire tant des idées que des phénomènes concrets. très forte : le concept d’objet n’est utilisable en dehors
des tâches informatiques que pour des objets suffisamment
Cette généralité revendiquée donne au modèle à objets des concrets. Dès qu’il s’agit de parler de couleur, de com-
atouts pour servir de base à la communication entre acteurs portement, d’étape de dialogue, de tâche, de principe de
de la conception, et donc pour placer les frontières, les inter- conception, ou de processus mentaux, il faut en revenir à la
faces, entre éléments de conception là où le projet le requiert : traduction sans concepts de base partagés entre les métiers.
– Il intègre les données et le calcul. C’est très favorable pour – Enfin, les langages à objets sont une libre application du
les programmeurs, mais aussi pour tous ceux qui ont à dia- concept d’objet imaginé par Alan Kay. À de rares excep-
loguer avec eux. C’est un bon exemple de concepts de base tions près, ils s’inscrivent dans le cadre du calcul procédu-
qui facilitent les traductions entre acteurs de la conception. ral, qui ramène toute exécution de programme à une suite
– Il atténue la frontière entre objets physiques et informa- d’instructions et d’appels de fonctions. Tout échange de
tiques. Cette frontière est indésirable en conception d’inter- messages est un appel de fonction, c’est-à-dire un frag-
faces, car d’une part de nombreux paradigmes d’interaction ment de dialogue : un appelant soumet des données (le
reposent sur la reproduction informatique de caractères at- contenu du message) à un appelé, lequel traite les données,
tribués à des objets physiques, et d’autre part certains logi- produit un résultat puis permet à l’appelant de poursuivre
ciels doivent reproduire des objets physiques ; c’est le cas son exécution. Dans cet échange, un objet prend l’initia-
des claviers virtuels par exemple. Cela permet de fixer les tive de s’adresser à un autre objet qu’il connaît, puis at-
frontières entre concepteurs là où le projet le requiert et non tend sa réponse. Cela éloigne le modèle à objets du concept
à l’interface entre le monde physique et le monde virtuel. intuitif d’objet, pour deux raisons. D’une part les concep-
– Il s’agit d’un modèle hiérarchique, qui rend compte des cas teurs d’interfaces savent bien que le dialogue n’est que l’un
multiples de découpage des tâches et des niveaux d’ana- des paradigmes d’interaction possibles. D’autre part, l’en-
lyse. On peut par exemple se mettre d’accord sur la struc- tité qui déclenche l’interaction n’est pas toujours celle qui
ture d’un objet sans détailler complètement ses compo- « connaît » le destinataire des messages, car dans les ordi-
santes. On peut aussi utiliser le modèle pour décrire des nateurs les sources d’événements préexistent souvent aux
parties de système dont la conception interne est inconnue comportements qu’elles déclenchent. En conséquence l’in-
mais dont il faut étudier les interactions avec les autres par- teraction entre entités, qui est l’un des éléments centraux
ties. C’est le cas, dans les systèmes homme-machine, de des échanges entre concepteurs, requiert des traductions
l’humain et de ses processus cognitifs et physiques. complexes pour s’exprimer dans le modèle à objets. Au
– Il offre des mécanismes pour définir des frontières entre ce sein même de l’informatique, ce problème a engendré des
qui est déjà décidé et ce qui ne l’est pas encore, à commen- dizaines d’années de recherche sur des principes alternatifs
cer par les concepts de classes et de dérivation. Toutefois, d’architecture et d’exécution des IHMs, à commencer par
il faut reconnaître que ces mécanismes sont surtout utilisés le modèle à événements. Il est donc logique que le modèle
par les informaticiens. à objets ne puisse être la lingua franca de la conception.
Depuis sa proposition dans les années 1990, la conception par Le modèle à objets a donc des défauts importants en tant
objets appliquée à l’IHM n’a néanmoins pas rencontré de suc- qu’ensemble de concepts de base à partager entre les acteurs
cès durable. Plusieurs raisons sont proposées ci-dessous pour de la conception de système homme-machine. Cela explique
expliquer cet échec. On peut les interpréter comme des diffi- pourquoi la conception par objets d’IHM n’a pas eu de succès
cultés qui perturbent la communication à certaines frontières généralisé. Mais ce modèle pose des problèmes aux program-
et donc compliquentle partage des tâches de conception. meurs d’IHM eux-mêmes, et cela donne une piste de solution
– Tout d’abord certains mécanismes de description semblent explorée dans la suite de cet article : s’appuyer sur des mo-
appropriés aux informaticiens mais moins aux autres mé- dèles alternatifs conçus pour l’informatique interactive afin
tiers. C’est le cas pour les mécanismes de classe et de dé- d’imaginer une base commune aux divers concepts manipu-
rivation, donc pour la relation entre cas général et cas par- lés par les concepteurs.
ticulier. Ça l’est encore plus pour le mécanisme d’abstrac-
tion proposé : les classes abstraites, qui spécifient des prin- DE L’OBJET AU COMPOSANT INTERACTIF
cipes sans les mettre en œuvre. Il semble que ce schéma De nombreuses propositions alternatives ou complémentaires
soit spécifique aux raisonnements des informaticiens, et on au modèle à objets ont été faites par les chercheurs en archi-
observe d’ailleurs que le principe des classes abstraites est tecture logicielle pour l’IHM. L’alternative décrite ici, celle
plus facile à expliquer en décrivant comment il est mis en des composants interactifs, est focalisée sur les faiblesses dé-
œuvre dans la mémoire de l’ordinateur. crites plus haut, à commencer par le problème du modèle pro-

4
cédural. Elle s’appuie sur des travaux théoriques en informa- Les composants interactifs
tique répartie, dont il faut d’abord introduire quelques bases. En substituant le modèle des processus à celui des instruc-
tions et des appels de fonctions, on transforme le modèle
Informatique répartie et théorie des processus à objets en un modèle de composants interactifs [6] : tout
Il n’y a pas qu’en conception et développement d’IHM que comme un objet est constitué de sous-objets qui échangent
le modèle procédural convient mal. Alors qu’en étudiant les des messages, un composant interactif est constitué de sous-
racines des langages de programmation courants on observe composants qui interagissent. La différence majeure est dans
à quel point ils sont influencés par le calcul [5], il existe de- la richesse des interactions que l’on peut décrire. Alors que
puis l’origine de l’informatique une approche alternative de dans le modèle procédural on est contraint à l’appel de fonc-
modélisation et de programmation, pour laquelle l’architec- tion, ici quatre schémas sont possibles :
ture de van Neumann est un choix parmi d’autres et non un – Appel de fonction ; étant donné un composant, on crée un
présupposé. Cette approche, qui se focalise sur la description second composant qui déclenche à volonté l’activation du
du monde comme un ensemble de systèmes qui interagissent premier. C’est ce qui se passe quand on imprime un texte
entre eux [20] et non comme un ensemble de calculs à effec- dans une console et, de manière plus complexe, quand on
tuer, est à la base des résultats sur les systèmes répartis. Ses maintient un objet graphique à l’écran.
applications pratiques en termes de génie logiciel ont été pour – Événement ; étant donné un composant, on en crée un se-
l’essentiel limitées à quelques langages pour ordinateurs pa- cond qui est activé quand le premier l’est. C’est ce qui
rallèles, et des intergiciels spécialisés dans la gestion de sys- se passe quand on s’abonne aux changements d’état d’une
tèmes répartis. Mais ses résultats théoriques sont au coeur de souris, ou à la réception de messages sur le réseau.
la modélisation et la preuve de systèmes critiques, et ont une – Aspect ; étant donnés deux composants, on en crée un troi-
influence tant sur l’ingénierie des réseaux que sur la plupart sième qui assure que le second est activé quand le premier
des approches formelles en IHM. Par exemple, les ICOs [17] l’est. C’est qui se passe quand on connecte des composants
et les ConcurTaskTrees [16] s’appuient sur des notions issues logiciels à la fois aux périphériques d’entrée et aux disposi-
de l’informatique répartie. Il existe plusieurs modèles théo- tifs d’affichage, ou quand on interconnecte des composants
riques des systèmes répartis. Outre les acteurs, qui corres- qui n’étaient pas destinés à fonctionner ensemble.
pondent à la définition qu’[Link] donnait à l’origine pour les – Routeur : deux composants sont créés indépendamment
objets 2 , les plus répandus sont les réseaux de Petri, utilisés l’un de l’autre, en utilisant la connaissance d’un troisième
dans les ICOs, et les algèbres de processus [13], qui sont à la composant qui assure que l’un est activé quand l’autre l’est.
base de la programmation réactive. C’est ce qui se passe dans les systèmes d’exploitation entre
les pilotes de périphériques et les applications.
Les processus sont parmi les concepts les plus fondamentaux Ces quatre styles d’interaction entre composants permettent
pour décrire l’interaction : un processus peut se définir par la des organisations différentes du travail, en fonction de quel
suite de ses interactions avec d’autres processus, et l’on peut programmeur réutilise quels composants existants. Mais sur-
construire une théorie où les seuls concepts sont ceux de pro- tout, ils correspondent à la variété des situations que les pro-
cessus et d’interaction [15, 10]. L’exécution d’un programme grammeurs d’interfaces ont à gérer : respectivement les sor-
se décrit alors comme la suite des interactions entre les pro- ties, les entrées, leur orchestration, et les systèmes d’exploita-
cessus qui le constituent. De même tout processus peut être tion. Qui plus est, la définition des composants interactifs peut
décrit comme un ensemble de processus plus élémentaires in- être étendue aux périphériques d’interaction voire aux autres
teragissant entre eux. Par exemple une animation résultera de objets du monde physique, en conservant les mêmes quatre
l’interaction entre une horloge, des objets graphiques et des types de connexions. En transformant ainsi le modèle à ob-
trajectoires. Cette régression vers des processus de plus en jets, on en conserve les atouts tout en palliant ses faiblesses :
plus élémentaires aboutit aux instructions de base de l’ordi-
nateur, décrites elles aussi comme des processus. – Le modèle intègre les données et le calcul, autant que le
modèle à objets. Mais surtout, il permet de décrire d’autres
En appliquant la même technique de régression, on peut dé- notions essentielles en IHM : comportements, horloges,
finir l’état d’un processus. Les interactions provoquent des sources d’événements, filtres de flots de données, etc.
transitions entre états, ce qui permet d’analyser le comporte- – Il atténue d’autant plus la frontière entre objets physiques
ment d’un processus sous forme de machine à états. Si l’on et informatiques qu’il décrit des schémas d’interaction plus
définit la valeur d’un processus comme la représentation de naturels : autant un objet physique ne dialogue pas, autant
son état dans un ensemble que l’on choisit à volonté, par il interagit. Les périphériques d’interaction et d’affichage,
exemple l’ensemble des couleurs, on peut alors construire des tout comme les objets physiques de l’interaction tangible,
processus abstraits qui sont « exécutés » par les processus plus se décrivent facilement comme des composants interactifs.
concrets. Par exemple, si un processus prend ses valeurs dans – Il est hiérarchique par construction.
l’espace des couleurs et reste toujours dans les nuances de – Il offre, si nécessaire, les mêmes mécanismes de structu-
vert ou de rouge, on peut construire sur cette base un proces- ration que les langages à objets puisqu’il en est un sur-
sus à deux valeurs, vert et rouge. On a ainsi défini une relation ensemble. Mais surtout, grâce au mécanisme de processus
de compatibilité, de raffinement, entre un processus abstrait et abstrait décrit plus haut, il permet de rendre compte de ce
un processus concret, entre un processus et un processeur. qu’un composant est bien la mise en œuvre, le raffinement,
d’un processus abstrait défini au préalable. Il suggère ainsi
de nouvelles manières de décrire des frontières entre élé-
2. voir http ://[Link]/fonc@[Link]/[Link] ments de conception, des contrats entre concepteurs.

5
– Le concept de composant interactif semble plus approprié cela inclue le matériel, voire les humains pour ceux qui en
que celui d’objet pour décrire des entités abstraites, à la fois acceptent une vision mécaniste.
parce que le mot lui-même évoque la notion abstraite d’as-
semblage plus que celle de réalité physique, et parce que À l’inverse, le mot « processus » est sans doute trop abstrait
l’interaction est un concept plus souple que celui d’échange pour que chacun s’imagine concevoir un processus. Même
de messages. Il n’est donc pas choquant d’envisager un s’il a l’avantage d’être applicable quasi-universellement, il
comportement ou une animation comme un composant in- convient mieux à la description et à l’étude des interactions.
teractif. Mais surtout, grâce à son articulation avec le mo- Le mot qui semble représenter le meilleur compromis est « sys-
dèle de processus (un composant interactif peut être décrit tème » : il est habituellement associé au concept d’interac-
par un processus), le modèle est compatible avec la des- tion 3 , il est d’ores et déjà utilisé par chaque métier pour dé-
cription de concepts véritablement abstraits : une activité, crire des notions soit concrètes soit abstraites, et ces usages
une tâche, une procédure et un processus cognitif ne sont sont compatibles avec la définition que nous souhaitons don-
sans doute pas des composants interactifs, mais ce sont des ner au mot, à commencer par le système informatique, le sys-
processus dont on peut facilement décrire l’interaction avec tème homme-machine, et le système cognitif. Par ailleurs, il
des composants interactifs. est cohérent de modéliser le comportement des systèmes par
– Et pour finir, il propose par construction une définition beau- des processus, comme c’est le cas pour les composants inter-
coup plus riche de l’interaction entre composants puisqu’il actifs. Ces derniers deviennent alors des cas particuliers de
est appuyé sur le modèle des processus interagissants. systèmes, produits ou manipulés par des informaticiens.

Somme toute, ce modèle de composants interactifs corres- La proposition avancée ici repose donc sur trois notions : on
pond à la notion intuitive d’objet telle qu’introduite par Kay, conçoit ou on met en interaction des systèmes, que l’on mo-
tout en étant enraciné dans un modèle de processus qui rend délise au besoin par des processus, ou le cas échéant par des
compte de phénomènes plus abstraits. Qui plus est, le modèle modèles dérivés (états, flots de données, etc). C’est donc une
de processus sous-jacent permet aussi de passer à volonté à conception à base de systèmes qui est proposée ou, en ac-
des modélisations par machines à états, réseaux de Petri ou ceptant la loi de l’anglicisme, une conception orientée sys-
flots de données, donc d’appliquer les résultats déjà dispo- tèmes. Les systèmes étudiés sont en interaction à des niveaux
nibles sur ces modèles. Il semble donc naturel de tenter la très variés, mais d’une manière qui peut être décrite avec
généralisation à la conception de systèmes homme-machine. les mêmes concepts théoriques : interaction entre système
humain et système informatique, entre composants interac-
VERS LA CONCEPTION ORIENTÉE SYSTÈMES tifs que l’on assemble, entre système perceptif et affichage,
Revenons donc vers notre problème de départ, qui est l’iden- entre humain, automatisme et procédure, voire entre systèmes
tification de concepts de base pour dialoguer entre métiers homme-machine (le contrôle aérien et l’avion, par exemple).
de conception, ou pour servir de cadre d’interprétation des À ce stade il n’est pas question de proposer des méthodes
concepts de chaque métier. Le modèle des composants inter- de conception orientée-système : cela nécessiterait des études
actifs compense certaines lacunes du modèle à objets pour pluridisciplinaires qui dépassent le cadre de cet article. Il s’agit
décrire les logiciels interactifs. Peut-on le généraliser afin de plutôt de stimuler l’intérêt des diverses communautés concer-
le rendre pertinent pour tous les acteurs de la conception, et nées et de se convaincre qu’il est possible d’y travailler en
réussir là où le modèle à objets a échoué ? Cela permettrait de traduisant sous forme de systèmes tout ce qui est conçu ou
clarifier les relations entre les différents métiers, de rendre les analysé lors de la conception d’un système homme-machine.
spécifications plus utilisables, et surtout d’adapter les proces- C’est l’objet des exemples ci-dessous, destinés chacun à un
sus d’ingénierie aux besoins de chaque projet plutôt qu’aux ou des métiers différents.
contraintes imposées par les frontières entre langages. J’es-
quisse ci-dessous un cadre conceptuel qui vise à remplir ce Situation 1 : conception logicielle
rôle et permettre la traduction des concepts propres à chaque Considérons un objet simple qui représente la console d’un
métier vers un langage commun. ordinateur dans les langages à objets usuels ; il a deux mé-
thodes print et beep. On peut voir la console comme un
Processus, composant, système composant interactif, donc un système, dont print et beep
Les noms ont un poids, nous l’avons vu à propos de la concep- sont deux sous-composants. Pour les activer, il faut les mettre
tion par objets : pour un designer, une interaction n’est pas un en interaction avec d’autres systèmes. Une souris est un sys-
objet. Si un cadre doit servir à tous, il est important de choisir tème physique relié à un composant logiciel qui la repré-
un nom neutre, qui corresponde le mieux possible à la na- sente, et possède des sous-composants nommés boutons, eux-
ture de ce que l’on étudie ou l’on conçoit. Ainsi, même si le mêmes contenant press et release. Idem pour le clavier.
modèle décrit plus haut est proche du concept originel d’ob- En utilisant un composant spécial nommé binding, on peut
jet, il est impensable de réutiliser le même nom, tant pour les fabriquer un composant qui met en interaction les trois sys-
raisons déjà évoquées que parce que son sens est figé pour tèmes et constitue un programme simple.
de nombreuses années. De même, le mot « composant » pos- <component id="console-logger">
sède un sens particulier pour les concepteurs logiciels, proche <binding source="[Link]" action="[Link]"/>
du modèle à objets ; de plus il est probable qu’il poserait des <binding source="[Link]" action="[Link]"/>
problèmes similaires pour traiter de concepts très abstraits. </component>
Convenons donc de réserver le mot « composant interactif »
à ce qui est manipulé par les informaticiens, quitte à ce que 3. définition : un système est un complexe d’éléments en interaction

6
Situation 2 : analyse d’une technique d’interaction l’ordinateur. Mais, si l’humain reste une partie du système
La plupart des acteurs de la conception parlent d’« événe- d’analyse, quelle sera la nouvelle interaction avec lui ? Autre-
ment clic » pour désigner ce qui se passe lorsqu’on sélec- ment dit, quelle sera l’IHM du nouvel algorithme ? S’il s’agit
tionne une icône sur un écran. Mais combien d’entre eux d’une interface visuelle, et sachant que le processus de lec-
sont conscients qu’il s’agit en réalité d’un enchaînement d’ac- ture mis en œuvre ne sera plus le même, comment vérifier si
tions, différent entre un écran tactile et une souris, et que cela le système global peut être plus efficace que l’ancien ? Des
a des conséquences tant en matière de programmation que modèles théoriques comme ScanVis [9] peuvent contribuer à
de performance humaine ? Avec la multiplication des moyens cette vérification en explicitant les processus mis en œuvre
d’interaction, cette complexité sous-jacente peut de moins en lors de la lecture. On voit à cette occasion comment les mo-
moins être ignorée. Par exemple, quels sont les conséquences dèles de performance de l’interaction peuvent s’inscrire dans
du passage d’un écran tactile à une caméra 3D et que faut- la vérification de l’architecture du système homme-machine.
il adapter ? Pour l’étudier il faut un langage commun entre
informaticien, designer d’interaction et ergonome. Situation 4 : tâches et processus mentaux
L’usage des processus et processeurs n’est pas nouveau en
Ces séquences d’interaction peuvent s’exprimer utilement en sciences cognitives, le modèle ICS en est un exemple. Sans
termes de systèmes en interaction : le cerveau connecté à la rentrer dans le débat entre connexionnisme et cognitivisme,
vue, au système moteur et à des capteurs tactiles, la souris il est intéressant de remarquer que le modèle des processus
constituée de systèmes mécaniques, d’un système d’échan- est un modèle de type « boîte noire » qui décrit ce qui est ob-
tillonnage et d’un système USB, l’ordinateur, son propre sys- servé sans porter de jugement sur le fonctionnement interne.
tème USB et son système d’exploitation, et une série de com- Cela se prête bien à décrire comment des systèmes peuvent
posants logiciels qui filtrent les signaux. Chaque système de interagir avec le système cognitif, et l’aspect hiérarchique du
cette chaîne apporte son propre comportement, ses contraintes modèle permet de transformer progressivement la boîte noire
de fonctionnement, et ses pannes, dans ce qui est perçu comme en boîte transparente au fur et à mesure que des modèles plus
un événement ponctuel. fins de la cognition sont proposés. Ainsi, on peut décrire la
Analyser ces systèmes et leurs interactions permet de mieux lecture d’une image comme une interaction entre l’écran et le
maîtriser la conception. Par exemple, dans le cas d’une souris, système de balayage et de détection de contours, puis éven-
l’interaction continue entre le système moteur et le système tuellement raffiner le modèle du système visuel pour décrire
« bouton » provoque dans ce dernier un soudain changement quels sous-systèmes sont à l’œuvre.
d’état qui est transmis à la fois par les capteurs tactiles du Quant aux tâches et activités, qui jouent un rôle important en
doigt et par le système électronique, créant ainsi deux pro- ergonomie, il peut être exagéré de les présenter comme des
cessus de rétroaction. Cette redondance joue un rôle dans la systèmes car ce sont des constructions très abstraites. Mais
robustesse de l’interaction, comme en témoignent les perfor- cela ne fait que souligner leur rôle descriptif, par opposi-
mances dégradées en cas de défaillance des pièces qui trans- tion à des objets que l’on construit. Ainsi, les activités sont
mettent le changement d’état au doigt (on peut considérer des processus résultat du fonctionnement de systèmes, par
alors que c’est le système homme-machine qui est en panne). exemple le système homme-machine ou le système homme-
Donc transposer le « clic » en utilisant une caméra 3D est environnement. Quant aux tâches, ce sont des processus abs-
délicat, car cette redondance est alors absente. Il faut donc traits, dont il faut vérifier que l’activité constitue bien un raf-
soit proposer un nouveau système pour supporter le proces- finement. On retrouve ainsi l’approche décrite dans [18] dès
sus manquant, soit accepter des performances dégradées. que l’on confronte les tâches aux modèles de systèmes homme-
Situation 3 : automatisation et partage de responsabilités machine sous forme de processus.
Une question fréquente de conception est celle de l’automa-
PERSPECTIVES
tisation totale ou partielle d’une tâche, dont les conséquences
sont souvent mal anticipées. Analyser le système homme- L’analyse proposée dans cet article est un point de départ plus
machine comme une collection de sous-systèmes mettant en qu’un résultat. Des environnements de développement à base
œuvre des processus permet de structurer la conception : la de composants interactifs vont bientôt être disponibles [6],
liste des processus requis doit être identifiée (exigences fonc- ce qui permettra l’expérimentation de la conception orientées
tionnelles) et tracée (spécification), puis les concepteurs dé- systèmes appliquée au logiciel. La possible généralisation à la
finissent les sous-systèmes qui les mettent en œuvre et véri- conception d’interfaces ouvre de nombreuses perspectives de
fient que les interactions entre sous-systèmes sont efficaces. recherche. Tout d’abord, les définitions esquissées ci-dessus
Chaque migration de processus d’un sous-système à l’autre pour les concepts de chaque métier auront besoin d’être ap-
doit s’accompagner de nouvelles vérifications. Le partage de profondies, et leur utilité et leur utilisabilité validées avec
responsabilités est ainsi traité comme l’architecture en sous- des professionnels de chaque métier. L’intérêt de disposer de
systèmes du système homme-machine. concepts de base communs devra aussi être évalué : quels
dialogues, quelles validations, quels contrats deviennent pos-
Les détecteurs d’armes dans les aéroports affichent des images sibles ? En cas de succès, on pourrait alors envisager de défi-
aux opérateurs chargés de les interpréter et donc de mettre en nir sur cette base des schémas répétables d’organisation dans
œuvre le véritable processus de détection. Certains envisagent les projets, au-delà du schéma global conception-spécification-
de remplacer une partie du processus mental de détection par conception dont les limites sont connues. On peut aussi envi-
des algorithmes d’analyse d’image. Cette automatisation re- sager à terme des techniques réutilisables de spécification (au
vient donc à déplacer un processus du cerveau humain vers sens « document contractuel »).

7
Il sera par ailleurs intéressant d’étudier les limites en lar- REMERCIEMENTS
geur du concept de système. Le système cognitif et le pro- Ce travail a été financé en partie par l’ANR (projet Istar) et le
cesseur humain ont déjà été évoquées, mais la dimension col- FUI (projet Medusa du pôle Mer). Il prend ses racines dans les
lective mérite aussi d’être étudiée. On sait par exemple que projets de conception ou recherches sur les outils et méthodes
pour construire un système socio-technique, il faut des outils, menés avec mes collègues d’IntuiLab et d’Intactile Design ;
mais aussi des méthodes, des procédures et des formations. ils se reconnaîtront. Merci à H. Gaspard-Boulinc et M. Ma-
Or qu’est-ce qu’une procédure sinon un processus ? Peut-on gnaudet pour leurs relectures et leurs suggestions.
la concevoir de la même manière qu’un système physique
ou informatique ? Peut-on migrer ce système d’un processeur REFERENCES
humain vers un processeur informatique, réalisant ainsi de 1. J. Accot et al. Formal transducers : models of devices
manière simple une délégation de tâche de l’humain vers l’au- and building bricks for the design of highly interactive
tomatisme ? De même, on peut voir les méthodes comme des systems. In Proc. DSVIS’97. Springer-Verlag.
processus, qui doivent être conçus mais aussi installés dans 2. G. Booch. Object-oriented analysis and design with ap-
les habitudes des opérateurs ; ainsi, la formation peut être vue plications. Benjamin/Cummings, 1994.
comme la création de nouveaux processus mentaux, et l’on 3. G. Booch et al. The Unified Modeling Language User
peut peut-être raisonner sur le succès d’une formation en uti- Guide. Pearson Education, 1999.
lisant les outils de l’analyse de la fiabilité des systèmes. Idéa- 4. G. Calvary et al. A la croisée de l’ingénierie de l’inter-
lement, les règles, lois et décrets qui contraignent les concep- action homme-machine et de l’ingénierie dirigée par les
teurs et opérateurs de systèmes critiques pourraient aussi être modèles. Technique et science informatiques, 29, 2010.
modélisés selon les mêmes principes et pris en compte dans 5. S. Chatty. Programs = data + algorithms + architecture.
la conception. In Proc. Engineering Interactive Systems, Lecture Notes
in Computer Science. Springer-Verlag, 2007.
Enfin, alors même que le présent travail met la conception au 6. S. Chatty. Supporting multidisciplinary software com-
centre du processus d’ingénierie et est donc en fort contraste position for interactive applications. In Proc. Software
avec la dérivation automatique de modèles, il peut servir de Composition, LNCS 4954. Springer-Verlag, 2008.
base à une convergence entre les deux approches. En effet, si 7. A. Cockburn. Agile Software Development. Addison-
l’on considère la conception comme une série d’enrichisse- Wesley Professional, 2001.
ments et de raffinements d’un ensemble de choix de concep- 8. D. Collins. Designing object-oriented user interfaces.
tion, on se rapproche du processus de base de l’ingénierie Benjamin/Cummings Publishing Company, 1995.
dirigée par les modèles. Améliorer la compatibilité entre mo- 9. S. Conversy et al. Visual scanning as a reference frame-
dèles et diminuer les coûts de traduction devient alors un ob- work for interactive representation design. Information
jectif commun aux deux approches, et peut permettre à terme Visualization, 10 :196–211, Sage, 2011.
une convergence. La dérivation de modèles deviendrait alors 10. A. Dittmar et P. Forbrig. A unified description forma-
l’un des outils utilisables pour la conception orientée système. lism for complex HCI-systems. In Proc. Software Engi-
neering and Formal Methods, IEEE, 2005.
CONCLUSION 11. E. Gamma et al. Design Patterns : Elements of Reusable
Dans l’optique d’une réflexion sur les méthodes d’ingénierie Object-Oriented Software. Addison-Wesley, 1995.
système pour l’interaction homme-machine, nous avons exa- 12. A. Goldberg et D. Robson. Smalltalk-80 : the language
miné les difficultés rencontrées par les acteurs de la concep- and its implementation. Addison-Wesley, 1983.
tion de logiciels interactifs à avoir une vision claire et parta- 13. C. Hoare. Communicating sequential processes. Com-
gée de leurs processus d’ingénierie. En analysant le statut res- munications of the ACM, 21(8) :666–677, 1978.
pectif de la spécification et des activités usuelles de concep- 14. A. C. Kay. The early history of Smalltalk. ACM SIG-
tion, on observe qu’un schéma où des métiers différents font PLAN, 28(3) :69–75, Mar. 1993.
chacun des choix de conception et définissent des contrats aux 15. E. A. Lee et A. Sangiovanni-Vincentelli. Comparing
frontières entre ces choix rendrait mieux compte de la réa- models of computation. In Proc. ICCAD 1996.
lité, pour autant qu’un langage ou un ensemble de concepts 16. G. Mori et al. CTTE : Support for developing and ana-
communs leur permettent d’interconnecter leurs productions. lysing task models for interactive system design. IEEE
Analyser en quoi le modèle à objets a échoué à devenir cette Trans. on Software Engineering, 28(2) :797–813, 2002.
base commune permet d’envisager une nouvelle solution où 17. P. Palanque et R. Bastide. Petri net based design of user-
les concepts d’interaction et de système jouent un rôle central. driven interfaces using the interactive cooperative object
Cette approche, la conception orientée systèmes, est ambi- formalism. In Proc. DSV-IS’94, 1994.
tieuse au premier abord mais n’a d’autre objectif que de reve- 18. P. Palanque et al. Validating interactive system design
nir à des évidences parfois oubliées : d’une part, les concepts through the verification of formal task and system mo-
d’architecture logicielle doivent être au service de la concep- dels. In Proc. EHCI’95. Chapman & Hall, 1995.
tion de la totalité du logiciel et il est donc logique de les re- 19. C. Schlienger et al. Une expérience de conception et de
mettre en question tant que la convergence n’est pas atteinte ; prototypage d’interfaces évoluées en milieu industriel.
et d’autre part, alors même que l’interaction est au coeur des In Actes d’IHM 2004, ACM Press, 2004.
modèles usuels des systèmes, il serait paradoxal qu’une disci- 20. P. Wegner. Why interaction is more powerful than algo-
pline centrée sur l’interaction et la conception de systèmes ne rithms. Communications of the ACM, 40(5), May 1997.
cherche pas à disposer de méthodes et de théories construites 21. T. Winograd et al. Bringing design to software. ACM
sur ces deux concepts. Press, 1996.