Conception et evaluation d’ IHM

Pourquoi ? Comment ?

Une sensibilisation à la problématique

Anne-Marie Déry - pinna@polytech.unice.fr

– Page 2

Quelques définitions

CHM Communication Homme MachineEtude de la conception des systèmes informatiques

contrôle aérien, centrale nucléaire : sécuritébureautique : productivitéjeux : engagement

Des utilisateurs

IHM Interface Homme Machine (1970)contact utilisateur système =

langage d'entrée +de sortie + gestion de l'interaction

Interaction Homme Machine (1980)Discipline englobant la conception, l'évaluation et le

développement de systèmes interactifs

– Page 3

IHM et la diversité des supports

Des supports variés avec des capacités d’interaction

Différentes : bornes – tables – vitrines – murs interactifs

Taille des écrans – multi touch ou non – utilisateur experts ou nonEnvironnement bruyant – sombre …

– Page 4

IHM et la diversité des supports

Des supports variés avec des capacités d’interaction

Différentes : des supports dédiés

Utilisateurs experts – efficacité sécuritémobilité

MÊMES USAGES MÊMES SERVICES

IHM et supports mobiles

– Page 6

IHM, utilisateurs et usages

Complexification de la conception ergonomique et

logicielle

Continuité de service

– Page 7

Problématique actuelle

Prendre en compte les avancées technologiquesnouveaux supports matérielsmasse de données sur net et intranetnouveaux moyens d'interactionsmultimédia : son, images

Prendre en compte la diversité des utilisateurs : des novices aux experts

Assurer le succès de l’utilisation des logiciels : les interfaces ?facilité d'utilisation même si le service offert est complexevoiture vs électroménagertéléphone : nouvelle gamme

– Page 8

Les enjeux de la mutation

De nouveaux problèmes à résoudre Prendre en compte le contexte dans l'interaction

Perception/modélisation/adaptation Prendre en compte la mobilité

Prendre en compte la continuité de service

Des solutions à des problèmes anciens à revoir les techniques d'interaction : windows, icons, menus, pointing Caméras, doigts, gestes : quand ? Pourquoi ?

Des problèmes classiques prennent une importance particulière concevoir pour plusieurs plates-formes assurer la sécurité et la confidentialité

– Page 9

Les enjeux de la mutation

CONSTAT :

Ingénierie au cas par cas insuffisante

Technicité accrue

Exigences utilisateurs croissantes

Coûts de développement et de maintenance

Cohérence ergonomique entre versions

Objectif non avoué

Augmenter

fiabilité, efficacité,

productivité

– Page 10

Comment y répondre ?

Faciliter l’adaptation des IHMComprendre les techniques d’interaction : Module NMISavoir développer : exemples continuité de services

(avec prise en compte du contexte et de la collaboration)

ET

VERIFIER L’UTILISABILITE de L’Interface

– Page 11

Utilisabilité des interfaces

Critères à mettre en œuvre :1.Faciliter l’apprentissage et l’usage2.Informer : donner des retours d'information rassurants, utiles et immédiats

Des moyens 1.Concevoir les IHM

La conception doit répondre aux besoins, connaissances et caractéristiques des utilisateurs

2.Evaluer les IHML’évaluation doit permettre de vérifier la bonne adéquation entre ce qui est

fourni et les attentes des utilisateurs

3. PrototyperLe prototypage doit valider des solutions logicielles adaptées

– Page 12

Utilisabilité des interfaces

conception, évaluation, prototypageau cœur du cycle de vie des IHM

– Page 13

Démarche

Appliquer le cycle de vie des IHM Identifier les rôles : Ergonome, Designer, Développeur, Déterminer les utilisateurs visés

Identifier la complexité des applications Prise en compte du contexte (lieu, temps, environnement) Collaboration (en mobilité ou non, synchrone /

asynchrone)

Identifier les techniques d’interactions adaptées ou en présence En entrée, En sortie

Mono ou multi modales ?

– Page 14

Analyse des besoins

Conception

Conception logicielle

Codage

Tests Unitaires

Tests d’intégration

Tests UtilisateursEvaluation ergonomique

Boîtes à outils

Mécanismes généraux

Modèle d’architecture logicielle

Espace de conception

Propriétés ergonomiques

Rôles et ActeursUtilisateurs - Ergonomes – Designers -

Développeurs

ETAPES DE L’EVALUATION ERGONOMIQUE :

CONCEPTIONEVALUATION

PROTOTYPAGE

ETAPES LOGICIELLES :

MODELES D’ARCHITECTUREBOITES À OUTILSTESTS UNITAIRES

Etapes du cycle de vie

Etapes Logicielles

ZOOM SURMODÈLES D’ARCHITECTURE LOGICIELLE

Organiser le code (rangement)

Simplifier (diviser régner)

Organiser le travail

Modifier (une partie)

Ré-utiliser

Notions : modularité, évolutivité, flexibilité

Architecture Logicielle et IHM : Pourquoi

?

Séparation possible –Code pour IHM–Code «Métier»

•Exemple –IHM différente pour une Gestion d’un stock de chaussures ou de bibelots ?–Linux sous gnome ou kde, le système change-t-il ?

•Objectif : éviter de tout modifier si on change la partie fonctionnelle ou la partie IHM

Architecture Logicielle et IHM : Pourquoi

?

– Page 19

Un problème classique

Des architectures logicielleshttp://tel.archives-ouvertes.fr/docs/00/04/82/79/HTML/2_2modelesinterface_referen.html

Tous les modèles partent du principe :un système interactif comporte une partie interface et une partie application pure

Cette dernière est souvent appelée noyau fonctionnel.

Le noyau fonctionnel est considéré comme préexistant, et les modèles de systèmes interactifs décrivent essentiellement la partie interface, ainsi que ses relations avec les objets du domaine.

Système interactif

utilisateur

Système interactif

Des architectures logicielles

La plupart des modèles identifient au moins trois types d'éléments :un ``coté utilisateur'‘ (présentations),

un ``côté noyau fonctionnel'‘ (interfaces du noyau fonctionnel, abstractions, modèles),

et des éléments articulatoires (contrôleurs, adaptateurs).

Système interactif

utilisateur

Des architectures logicielles : modèles architecturaux

Seeheim

Premier modèle (groupe de travail à Seeheim en 1985) - destiné au traitement lexical des entrées et sorties dans les interfaces textuelles – a servi de base à beaucoup d'autres modèles.

Retour sémantique direct

utilisateur NF

Des architectures logicielles : modèles architecturaux

Arch

utilisateur

Le modèle Arch [1992] 5 composants et 3 types de

données

objets du domaine

objets dudomaine

objets de présentation

objets d'interaction

Arch

utilisateur

Composant d'interaction - ensemble des widgets (objets interactifs) + communications avec les périphériques physiques – Composant de présentation - représentation logique des widgets indépendante de la plate-forme.

Contrôleur de dialogue - responsable du séquencement des tâches et du maintien de la consistance entre les vues multiples.

Adaptateur du domaine - responsable des tâches dépendantes du domaine qui ne font pas partie du noyau fonctionnel mais qui sont nécessaires à sa manipulation par l'utilisateur.

Noyau fonctionnel représente la partie non interactive de l'application.

objets du domaine

objets dudomaine

objets de présentation

objets d'interaction

Modèles à agents

utilisateur utilisateur

Le modèle MVC (Modèle, Vue, Contrôleur)

Smalltalk [Goldberg and Robson, 1981].

modifiabilité + conception itérative + compatibilité avec

les langages à objets.

utilisateur utilisateur

les systèmes interactifs = une hiérarchie d'agents.

Un agent MVC = un modèle, une ou plusieurs vues, et un ou plusieurs contrôleursmodèle = noyau fonctionnel de l'agent. (entier, chaîne de caractères ou objets)

Le modèle notifie les vues à chaque fois que son état est modifié par le noyau ou par ses contrôleurs.

La vue (constituée d'objets graphiques) maintient une représentation du modèle pour l'utilisateur, mise à jour à chaque notification d'état.

Le contrôleur reçoit et interprète les événements utilisateur, les répercutant sur le modèle (modification de son état) ou sur la vue (retour instantané).

PAC

PAC

PAC

utilisateur

modèle à agents PAC (Présentation, Abstraction, Contrôle) [Coutaz, 1987] = hiérarchie d'agents.

présentation = comportement en entrée et en sortie de l'agent pour l'utilisateur. Abstraction = la partie sémantique de l'agent. Contrôle = consistance entre la présentation et l'abstraction,. Abstraction : équivalent modèle de MVC,présentation : fusion des composants vue et contrôleur. Le composant contrôle n'a pas d'existence explicite dans le modèle MVC.

Modèles à agents

PAC

PAC

le modèle PAC peut être appliqué à plusieurs niveaux d'un système interactif. Une application interactive peut ainsi être décrite comme une hiérarchie d'agents disposés sur plusieurs couches d'abstractions

PAC/Amodeus = Arch + Pac avec hiérarchie PAC dans le contrôleur

– Page 29

Zoom : Architecture MVC

•Smalltalk[Goldberg et Robson1979-1983] –Model : modélisation (données et comportement)

–View: représentation manipulable de l'objet–Control : interprétation des entrées

Séparer dans le code–les données (le Modèle),–La ou les Vues,–Le Contrôle

•V s’abonne à M•C s’abonne à V•C modifie M et V

– Page 30

Le contrôleur au centre de la communication

– Page 31

Plusieurs vues – 1 modèle

– Page 32

Exemple

Mise en garde

La mise en œuvre de MVC dans une application n’est pas une tâche aisée : Introduit un niveau de complexité assez élevée Implique une bonne conception dès le départ

Peut prendre du temps au développement En faire gagner lors de l’évolution de l’application

Conseillée pour les moyennes et grandes applications amenées à être maintenues, étendues et pérennes

33

Mise en place

Exemple assez simple d’une application qui permet de modifier un volume.

Plusieurs vues pour représenter le volume et après toutes modifications, toutes les vues devront être synchronisées.

Conseils : dans une grosse application, il est important de faire différents packages pour les différentes préoccupations

34

Le modèle : la base

35

public class VolumeModel { private int volume; public VolumeModel(){ super(); volume = 0; } public int getVolume() { return volume; } public void setVolume(int volume) { this.volume = volume; }}

Pour la notification

Pour permettre la notification de changement de volume, on utilise des listeners

On crée donc un nouveau listener (VolumeListener) et un nouvel événement (VolumeChangeEvent)

36

Le listener et l’event

37

import java.util.EventListener;public interface VolumeListener extends EventListener { public void volumeChanged(VolumeChangedEvent event);}

import java.util.EventObject;public class VolumeChangedEvent extends EventObject{ private int newVolume; public VolumeChangedEvent(Object source, int newVolume){ super(source); this.newVolume = newVolume; } public int getNewVolume(){ return newVolume; }}

Implémentation du système d’écouteurs dans le modèle (1/2)

38

import javax.swing.event.EventListenerList;public class VolumeModel { private int volume; private EventListenerList listeners; public VolumeModel(){ this(0); } public VolumeModel(int volume){ super(); this.volume = volume; listeners = new EventListenerList(); } public int getVolume() { return volume; } public void setVolume(int volume) { this.volume = volume; fireVolumeChanged(); }

Implémentation du système d’écouteurs dans le modèle (2/2)

39

public void addVolumeListener(VolumeListener listener){ listeners.add(VolumeListener.class, listener); } public void removeVolumeListener(VolumeListener l){ listeners.remove(VolumeListener.class, l); } public void fireVolumeChanged(){ VolumeListener[] listenerList = (VolumeListener[])

listeners.getListeners(VolumeListener.class); for(VolumeListener listener : listenerList){ listener.volumeChanged(

new VolumeChangedEvent(this, getVolume())); } }}

Ce que l’on a maintenant

Le modèle est maintenant capable d’avertir tous ses écouteurs à chaque changement de volume

En fonction de l’application, il est possible d’imaginer plusieurs listeners par modèles et d’autres événements dans les listeners (par exemple quand le volume dépasse certains seuils)

Remarque : le modèle peut devenir très vite conséquent

40

Pré-requis pour le contrôleur

Pour éviter d’être dépendant de Swing, on va créer une classe abstraite représentant une vue de volume

41

public abstract class VolumeView implements VolumeListener{ private VolumeController controller = null; public VolumeView(VolumeController controller){ super(); this.controller = controller; } public final VolumeController getController(){ return controller; } public abstract void display(); public abstract void close();}

Le Contrôleur

Manipulera des objets de type View et non plus de type Swing

Un seul contrôleur sera créé dans un soucis de simplicité puisque les 3 vues font la même chose.

Dans le cas de vues complètement différentes, il est fortement conseillé d’utiliser plusieurs contrôleurs

42

Les vues

Nous supposons 3 vues (dans le cadre du cours, nous n’en montrerons qu’ une) : Une vue permettant de modifier le volume avec un

champ de texte et valider par un bouton Une vue permettant de modifier le volume à l’aide

d’une jauge + bouton pour valider Une vue listant les différents volumes

Toutes ces vues sont représentées par une JFrame

43

Contrôleur (1/2)

44

public class VolumeController { public VolumeView fieldView = null; public VolumeView spinnerView = null; public VolumeView listView = null; private VolumeModel model = null; public VolumeController (VolumeModel model){ this.model = model; fieldView = new JFrameFieldVolume(this, model.getVolume()); spinnerView = new JFrameSpinnerVolume(this, model.getVolume()); listView = new JFrameListVolume(this, model.getVolume()); addListenersToModel(); } private void addListenersToModel() { model.addVolumeListener(fieldView); model.addVolumeListener(spinnerView); model.addVolumeListener(listView); }

Contrôleur (2/2)

45

public void displayViews(){ fieldView.display(); spinnerView.display(); listView.display(); } public void closeViews(){ fieldView.close(); spinnerView.close(); listView.close(); } public void notifyVolumeChanged(int volume){ model.setVolume(volume); }}

Les vues

Nous allons faire 3 vues (dans le cadre du cours, nous n’en montrerons qu’ une) : Une vue permettant de modifier le volume avec un

champ de texte et valider par un bouton Une vue permettant de modifier le volume à l’aide

d’une jauge + bouton pour valider Une vue listant les différents volume

Toutes ces vues sont représentées par une JFrame

46

JFrameField (1/3)

47

import java.awt.event.ActionEvent;import java.awt.event.ActionListener;import java.text.NumberFormat;import javax.swing.*;import javax.swing.text.DefaultFormatter;public class JFrameFieldVolume extends VolumeView

implements ActionListener{ private JFrame frame = null; private JPanel contentPane = null; private JFormattedTextField field = null; private JButton button = null; private NumberFormat format = null; public JFrameFieldVolume(VolumeController controller) { this(controller, 0); } public JFrameFieldVolume(VolumeController controller, int volume){ super(controller); buildFrame(volume); }

JFrameField (2/3)

48

private void buildFrame(int volume) { frame = new JFrame(); contentPane = new JPanel(); format = NumberFormat.getNumberInstance(); format.setParseIntegerOnly(true); format.setGroupingUsed(false); format.setMaximumFractionDigits(0); format.setMaximumIntegerDigits(3); field = new JFormattedTextField(format); field.setValue(volume); ((DefaultFormatter)field.getFormatter()).setAllowsInvalid(false); contentPane.add(field); button = new JButton("Mettre à jour"); button.addActionListener(this); contentPane.add(button); frame.setContentPane(contentPane); frame.setTitle("JFrameSpinnerVolume"); frame.pack(); }

JFrameField (3/3)

49

@Override public void close() { frame.dispose(); } @Override public void display() { frame.setVisible(true); } public void volumeChanged(VolumeChangedEvent event) { field.setValue(event.getNewVolume()); } public void actionPerformed(ActionEvent arg0) { getController().notifyVolumeChanged(Integer.parseInt(field.getValue().toString())); }}

Vous avez compris MVC ?

UN EXEMPLE SIMPLE

– Page 51

L’exemple du login

2 vues parmi d’autres

IHM en Anglais

IHM en français

– Page 52

Un modèle

3 variables d’instances log, password, check

Des méthodes logCheck passwordCheck connect

– Page 53

Cas d’interaction

Cas no 1le bouton Log in implique la vérification login et

password à partir des données saisies.Les données peuvent être modifiées jusqu’au moment de

l’utilisation du boutonAction : connexion ou un message d’erreur

– Page 54

Cas d’interaction

Cas no 2le bouton Log in implique la vérification login password

à partir des données saisies.Les données peuvent être modifiées jusqu’au moment de

leur validation par un retour charriotActions : connexion ou un message d’erreurLes champs de saisie sont bloqués après retour charriot

– Page 55

Cas d’interaction

Cas no 3 :La saisie des données est validée au premier retour chariot

Actions : vérification des données faite au fur et à mesure pour le login puis pour le password ce qui peut entrainer un message d’erreur

connexion au moment par click sur le bouton

ETAPES DE L’EVALUATION ERGONOMIQUE :

CONCEPTIONEVALUATION

PROTOTYPAGE

ETAPES LOGICIELLES :

MODELES D’ARCHITECTUREBOITES À OUTILSTESTS UNITAIRES

Etapes du cycle de vie

– Page 57

Conception : Modélisation de l’utilisateur

Objectifs identifier le(s) type(s) d’utilisateurs en présence Identifier les besoins des utilisateurs Identifier leurs compétences et leurs habitudes

Comment faire ? Technique des questionnaires Technique des entretiens Tri Focus Group

– Page 58

Conception : Formaliser

Modélisation des utilisateurs Technique des Personas

Modélisation des besoins utilisateurs Description des taches HTA, UAN, CTT

– Page 59

Prototypage

Maquette basse fidélité Minimum de design pour se concentrer sur la

navigation et les taches Maquettage papierà vos papiers et à vos ciseaux

Fonctionnalités simulées Technique du magicien d’Oz Implémentation d’un scénario

– Page 60

Evaluation

Evaluation coopérative Évaluation centrée utilisateurs

Evaluation heuristique Evaluation par analyse Grille Xerox

– Page 61

Prototypage V2

Mise en œuvre

Charte graphique Graphisme / animation Fonctionnalités Architecture Logicielle

– Page 62

Dimensions de l’espace problème

Trois axes d’étudeTechniques d’interaction

Collaboration

Contexte

– Page 63

Illustration

Une définitionDes exemples

Scénari

Vidéo

– Page 64

Dimensions de l ’espace problème prise en compte du Contexte

Techniques d’interaction

Collaboration

Contexte

– Page 65

Une définition du terme contexte

3 axes pour mesurer un changement de contexte L’utilisateur (novice, avancé, handicapé, ...) Le device (smart phone, grand écran, vocal, tactile…) L’environnement (luminosité, bruit, ….)

En situation de mobilité le plus souvent Découverte de l’environnement physique –

reconnaissance de capteurs Adaptation de l’application au nouveau contexte par

rapport au besoin de l’utilisateurQuelle situation ? Avec qui ? Avec quoi ? Où ?

– Page 66

Système interactif sensible au contexte

Système interactif sensible au contexte capable d’identifier les circonstances qui entourent l’action

utilisateur en vue d’offrir des services contextualisés offre sélective d’information décoration contextuelle pour recherche ultérieure

Contexte : ensemble de propriétés de phénomènes physiques qui peuvent être captées

– Page 67

Identification des dispositifs d’interaction

Le dispositif du dépanneurreconnait le matérielLe dépanneur peut accéder à la fichetechnique et à la dsiponibiltédes pièces….

– Page 68

+ Prise en compte de la localisation

Profiter d’un dispositif de sortie plus adapté

Situer sur un plan et fournir des informations

– Page 69

Travaux de recherche

Migratory User Interface videos 1 et 21. Achat à distance d’un mobile vers une télévision2. Réservation de voyageVidéo Multi device User Application : Home Applications

http://giove.isti.cnr.it/videos/8

– Page 70

Dimensions de l’espace problèmeGestion du collaboratif

Selon trois axesTechniques d’interaction

Collaboration

Contexte

– Page 71

Une définition du terme collaboration

Une application collaborative :application qui permet d’atteindre un but à plusieurs

Plusieurs utilisateurs travaillent ensemble pour réaliser une ou plusieurs taches.

Quels utilisateurs ? Quand ? Comment ?

– Page 72

Collaboration et mobilité : découpage spatio-temporel

Déplacement dans l’espaceVariation dans le temps : synchronisme/

asynchronisme

local distant

asyn

chro

ne

syn

chro

ne

– Page 73

Mobilité : nouveau découpage spatial

Etude selon les lieux d’interaction et non la distance

CONFINE : lieu de l’interaction délimité

VAGABOND : lieu de l’interaction n’importe où

Localisée : Les participants sont ensemble

Non localisée : Les participant sont dispersés

– Page 74

Vidéos

http://atelierihm.polytech.unice.fr

Vidéos ScrapBooking et Echange de cartes de visite

– Page 75

Dimensions de l ’espace problèmePrise en compte et mise en place de techniques

d’interaction

Techniques d’interaction

Collaboration

Contexte

– Page 76

Une définition du terme technique d’interaction

Une technique d’interactionUne technique qui permet de récupérer les

données via un dispositif d’entrée auprès d’un utilisateur pour les transmettre à une application et de fournir des résultats à un utilisateur via un dispositif de sortie

Quel type de dispositif ? Pour quel utilisateur ? Pour quel usage ?

– Page 77

Un peu d’historique : Plate-forme Magic

Camera + Micro

Casque + Ecouteurs

Capteur d’orientation

Stylos

Tablette + Extenseur de port

Réseau sans fils

– Page 78

Expérience Interface « Baby face » : multimodalité

Technique = <d, s>Go to the middle of the message

T = <caméra-doigt, gestes> T = <micro, pseudo LN>

T = <ordinateur, gestes> T = <stylet, manipulation directe>

– Page 79

Interface « Baby face » Technique du magicien d’Oz

Magicien d ’oz

Compère Sujet observé

– Page 80

Interface « Baby face » : analyse des résultats

Usage des modalités par les sujetsToutes commandes / Toutes sessions

Vocale

Tactile

Gestuelle

Embodied

– Page 81

Interface « Baby face » conclusion ?

Usage des techniques d ’interaction par les sujets

Variabilité inter-individuelle importante dans l ’usage (fréquence, préférences variées)

SpécialisationPeu de redondance et de complémentarité

– Page 82

Travaux de recherche

Utilisation des techniques : Tilt Interaction for mobile Museum guide for Blind users

http://giove.isti.cnr.it/videos/8

De nouvelles techniques de visualisation :http://iihm.imag.fr/demo/hcpmobile/

ATTENTION !http://mail.google.com/mail/help/motion.html

MINI PROJET POLYTECH ANNEE 2005

Illustration par l’exemple

– Page 84

Mosaïques de télévision

Analyse des mosaïques de télévision (CanalSat ou Free) peu intuitivesmal conçues

Objectif : construire un système de navigation plus intuitif.

Public visé : Adolescents & adultes

– Page 85

POINT FORT

Evaluation coopérative de l’existant et du prototype final Définition des scénari Maquette basse résolution Utilisation adaptée du modèle de taches

– Page 86

Scénarios de l’existant

Conception des scénarios

Scénarios conçus en fonction des problèmes soulevés par les utilisateurs lors de la passation du questionnaire

Conception de 5 scénarios accès à une chaîne par son nom accès à une chaîne par son numéro modification du volume sonore accès à une chaîne par son thème navigation au sein des écrans de la mosaïque

– Page 87

Scénarios de l’existant

Pré-tests des scénarios

Évaluation du temps nécessaire à la passation Amélioration des scénarios

– Page 88

Scénarios de l’existant

Tests des scénarios

Enregistrement vidéo et papier des réponses Types d’utilisateurs : experts et novices Nombre de participant : 5 Types de mosaïques : CanalSat et Freebox

– Page 89

Modèles de tâches

– Page 90

Bilan des scénarios

Résultats des tests utilisateurs Utilisateurs insatisfaits

Principales raisons :

Mosaïque = chaîne 1 (a changé en janvier : chaîne 8 …)

Manque d’information sur les programmes en cours

Difficile de distinguer les chaînes payantes des gratuites

…

– Page 91

Proposition d’amélioration

Réalisation d’un maquette de bas niveau Conçue en fonction des besoins des utilisateurs

– Page 92

– Page 93

Scénarios de la maquette

Conception de nouveaux scénarios à partir de la maquette de bas niveau

En réadaptant les scénarios précédents

Mise en place de 6 scénarios Navigation au sein des écrans de la mosaïque Accès à une chaîne par son thème Accès aux films prochainement diffusés Accès à une chaîne par le nom de la chaîne Ajout de chaînes dans la catégorie « mes favoris »  Achat d'une chaîne

– Page 94

Scénarios de la maquette

Modèle de tache de l’existant

Modèle de tache de la maquette de bas niveau

– Page 95

Ce cours ne serait pas ce qu’il est sans …

Mes collègues chercheurs en IHM, la richesse de nos discussions et de leurs sites web

Mes anciens étudiants, leurs retours instantanés et leurs mini projets

Mes contacts industriels avec les collaborations recherche et les encadrements communs d’étudiants du parcours

– Page 96

Videos : Migration continuité de services adaptation

execution http://giove.isti.cnr.it/videos/8http://www.usixml.eu/effective-ie-done/mediahttp://atelierihm.polytech.unice.frhttp://iihm.imag.fr/demo/

De quoi réfléchir :

http://www.youtube.com/watch?v=vyUXEbe7Fxs