Télé-Procédure de Gestion d Incidents : Spécifications et Prototype. By Sébastien Pinel Performed at Laboratory LIG Equipe IIHM Université Joseph Fourrier Grenoble In partial fulfillment of the requirements of the Master 1 Informatique Program Université de Grenoble, Master 1 Informatique UFR IMAG Informatique et Mathématiques Appliquées Report of Intership, February 16 - August 28, 2009
Télé-Procédure de Gestion d Incidents : Spécifications et Prototype. 2 Executive summary report Ce rapport détaille mon stage durant les 4 derniers mois en tant que membre de l équipe IIHM du LIG à Grenoble. Ce stage a pour but de spécifier les attentes d un logiciel de télé-procédure dans le cadre d une déclaration d incident survenu dans un lycée (Lieu généralisé par la suite) et enfin de réaliser un prototype qui sera présenté au salon des Maires et des collectivités locales les 17, 18, 19 Novembre 2009. Ce stage représente une étude de cas dans le projet MyCitizSpace et s ancre dans une politique globale de dématérialisation des procédures administratives. Ainsi, ce rapport présentera les différentes étapes par lesquels je suis passé pour réaliser ce prototype. J ai effectué la description de ces étapes par analyse critique. En effet, j ai préféré me focaliser sur les problèmes rencontrés, la réflexion sur ces mêmes problèmes et la solution que je leur ai apportés plutôt que de donner de but en blanc le résultat final.
Télé-Procédure de Gestion d Incidents : Spécifications et Prototype. 3 Table of Contents 1 Introduction... 4 2 Analyse des besoins... 5 2.1 Scénarios... 5 2.2 Spécification des utilisateurs... 5 2.2.1 Citoyen... 6 2.2.2 Personnel lycée... 6 2.2.3 Personnel région Midi-Pyrénées... 6 2.3 Spécification des plates-formes... 6 2.3.1 Analyse critique des environnements logiciels... 6 2.3.2 Etude comparative des téléphones haut de gamme... 6 2.4 Géolocalisation... 7 2.4.1 Triangulation GSM... 7 2.4.2 GPS... 8 2.4.3 Plans... 8 2.4.4 Autres... 8 3 Conception... 9 3.1 Modèle des tâches... 9 3.2 Modèle des concepts... 9 3.3 Maquettes... 10 4 Prototype... 11 5 Conclusion... 12 6 Remerciements... 13
Télé-Procédure de Gestion d Incidents : Spécifications et Prototype. 4 1 Introduction Depuis quelques années, l'administration Française met en place une politique de dématérialisation des procédures pour simplifier les démarches du citoyen et faciliter la gestion administrative. Pour exemples, la télé-déclaration d'impôt sur le revenu, les demandes d'intervention sur la voie publique ou encore les demandes d'actes d'état civil. Toutefois, la complexité des procédures (diversité des intervenants, durée de réalisation, volume et sensibilité des informations personnelles), la diversité des types de points d'accès et l incohérence des Interfaces Homme-Machine (IHM) restent aujourd hui des difficultés clé. Le projet MyCitizSpace vise à doter les administrations locales (Collectivités Locales et Territoriales) et centrales (Ministères, Organismes Nationaux) d outils logiciels performants et agiles, garants, pour le citoyen, d IHM de qualité, satisfaisant en particulier les exigences de sécurité, ubiquité et accessibilité. L approche explorée dans le projet est une Ingénierie Dirigée par les Modèles (IDM). L'ambition est de produire un atelier IDM permettant aux différents acteurs (Maîtrise d'ouvrage, Maîtrise d'œuvre, Expert Métier, CNIL) de produire, de façon itérative et collaborative, des télé-procédures efficaces, capables de s adapter aux dispositifs d interaction de l utilisateur (PC, téléphone, etc.) dans le respect des propriétés attendues (fonction et ergonomie). Ce projet est composé de différents partenaires académique (INRIA, IRIT, LIG) et industriels (ALMETIS, GENIGRAPH) avec comme coordinateur GENIGRAPH.
Télé-Procédure de Gestion d Incidents : Spécifications et Prototype. 5 2 Analyse des besoins Le signalement d un incident doit pouvoir être déclaré rapidement, lors de sa découverte, via une plate-forme mobile. Pour offrir un service accessible par le plus grand nombre d utilisateurs, le système doit être capable de s adapter aux différentes plates-formes mobiles communément utilisées (téléphones simples, Smartphones, etc.). On appelle «plasticité» cette capacité de l IHM à s adapter au contexte d usage (utilisateur, plate-forme, environnement) dans le respect de propriétés centrées utilisateur. Pour ce faire, nous avons élaboré des scénarios d usage qui illustrent des spécifications matérielles différentes selon les téléphones. Ensuite, nous avons choisi : deux téléphones avec des capacités aux deux extrêmes (tout ou presque rien), le système de développement qui permette non seulement d être compatible avec le plus de plateformes mobiles possible, mais aussi de développer une télédéclaration plastique, capable de s adapter aux deux téléphones choisis Ainsi, nous avons choisit le système avec le plus de personnes possibles mais aussi permettant d avoir des capacités aux deux extrêmes. 2.1 Scénarios Pour avoir une meilleure idée des attentes des utilisateurs, nous avons mis en place des scénarios. Ces scénarios mettent en avant des utilisateurs possédant des téléphones avec des caractéristiques variées afin de couvrir les différentes gammes de téléphones proposés dans le commerce. Mais également des utilisateurs dans des contextes différents (Ex. un utilisateur avec un téléphone comportant un GPS/Accéléromètre et connecté à internet qui veut déclarer un nid de poule dans la rue de son domicile ou un intendant avec un téléphone minimal qui veut déclarer une dégradation dans une salle de son lycée. 2.2 Spécification des utilisateurs Cette tâche fut ardue car chacun des partenaires avaient une vision plus ou moins différente du public visé donc nous avons essayé de contenter tout le monde en gardant une vision général avec le citoyen mais aussi une vision centré utilisateur métier. Autre point difficile a été de spécifier précisément les besoins des utilisateurs métiers. Ainsi pour ce faire, notre contact à la région Midi-Pyrénées a du effectuer des entretiens avec les différents acteurs afin d obtenir leur attentes sur le logiciel final. Les rendez-vous étant espacé dans le temps les informations sont arrivées au comptegoutte.
Télé-Procédure de Gestion d Incidents : Spécifications et Prototype. 6 2.2.1 Citoyen Ce type d utilisateur est notre manière de généraliser les attentes de la déclaration d incident dans le cas où une personne quelconque effectue cette démarche. (Photo, lieu, identité, type d incident, commentaire) 2.2.2 Personnel lycée Cette catégorie d utilisateur représente les intendants et les ARL (Personnel d entretien) 2.2.3 Personnel région Midi-Pyrénées Cette catégorie d utilisateur représente les agents DES (Direction de l Education et des Sports) et les agents DAJ (Direction des Affaires Juridiques). Ainsi, ces agents auront besoin de pouvoir réaliser un descriptif détaillé de l incident incluant les causes de l incident (si elles sont connues), les actions effectuées pour la prise en charge de l incident et si une intervention est nécessaire pour résoudre ce problème. 2.3 Spécification des plates-formes 2.3.1 Analyse critique des environnements logiciels Afin de trouver l environnement logiciel le plus adapté à nos besoins, nous avons effectué une analyse critique des principaux environnements disponibles sur téléphone. Lors de cet analyse, nous avons pu remarquer que chacun avait des avantages spécifiques mais que chacun avait un gros défaut dans l utilisation dans notre contexte (Ex. JavaME, Symbian OS : incompatibilité entre téléphones, iphone OS : plasticité non vérifiée) sauf pour le système d exploitation Windows Mobile. 2.3.2 Etude comparative des téléphones haut de gamme Afin de choisir le téléphone haut de gamme, nous avons également réalisé une étude comparative des téléphones haut de gamme. Le modèle qui est ressorti de cette étude est le HTC Touch HD (Blackstone) possédant GPS/Accéléromètre/WIFI/APN 5 méga pixels et une résolution de 480*800. Celui-ci représentera notre borne supérieure. Notre borne inférieure quant à elle sera représente par un émulateur.
Télé-Procédure de Gestion d Incidents : Spécifications et Prototype. 7 2.4 Géolocalisation La géolocalisation est un élément fonctionnel clé de ce logiciel. En effet, afin de déclarer un incident, il est primordial de savoir le situer dans un premier temps. Cette action peut être réalisée par différents matériels présents sur le téléphone. Par la suite je vais m efforcer de donner la liste exhaustive des techniques applicables à notre contexte d usage. 2.4.1 Triangulation GSM Cette technique de géolocalisation permet avec un téléphone minimale de pouvoir se situer avec une précision qui cela dit est moyenne (~200 mètres en milieu urbain, 2km en milieu rural) mais qui reste quand même utilisable dans notre logiciel. Le principe de cette technique est simple : il existe des antennes-relais GSM dans toute la France ou presque desquelles nous connaissons leur coordonnées GPS. chaque téléphone doit se connecter à une de ces antennes afin d utiliser la téléphonie. Donc en captant assez de signaux d antennes-relais, nous pouvons utiliser une technique de triangulation afin d estimer la position de l utilisateur. Pour affiner cette technique, nous pouvons utiliser des informations sur la puissance et la qualité du signal en les utilisant de la manière suivante : Fig. 1 Un utilisateur situé entre 2 antennes-relais.
Télé-Procédure de Gestion d Incidents : Spécifications et Prototype. 8 On pourra utiliser ces informations afin de calculer le barycentre des 2 antennes-relais représenté par une étoile en affectant à chacune d elles un poids calculé par exemple de la manière suivante : poids = qualité / portée. Avec la portée donnée en mètre et la qualité en pourcentage. Et enfin, afin de trouver les coordonnées GPS des antennes-relais nous avons utilisé une requête au service Google Maps. 2.4.2 GPS Cette technique, la plus connue de tous, utilise une puce GPS ou un GPS externe afin de communiquer avec des satellites et finalement de repérer en temps réel la position de l utilisateur. Cette technique possède une très bonne précision (~20 mètres) mais est sujette aux aléas du temps. Elle a aussi comme inconvénients de ne pas être utilisable à l intérieur des bâtiments ou à proximité de bâtiments élevés et aussi que tous les téléphones ne possèdent pas cette puce GPS. Donc cela restreint son utilisation dans notre contexte. 2.4.3 Plans Les 2 techniques précédentes n étant pas utilisables à l intérieur d un bâtiment (précision trop faible ou incompatibilité), il nous a fallu trouver une méthode afin de réaliser ce positionnement. C est donc ici que les plans entre en jeu. En effet, chaque bâtiment possède un plan déterminé de leur structure. Le but est simple, le bâtiment peut être situé par la technique de triangulation par GSM et à partir de là on récupère le plan du bâtiment sur lequel on positionnera à l aide du curseur/stylet l incident. (Exemple de plan) 2.4.4 Autres D autres techniques auraient pu être envisagées. En effet, nous aurions pu réaliser une géolocalisation par wifi. Néanmoins le wifi étant interdit dans les établissements scolaires, l utilité aurait été minime. Ensuite, on aurait pu mettre en place la technique de géolocalisation par adresse IP mais celle-ci est vraiment inutile sur téléphone portable.
Télé-Procédure de Gestion d Incidents : Spécifications et Prototype. 9 3 Conception 3.1 Modèle des tâches Le modèle des tâches étant relié avec la spécification des utilisateurs et de leurs besoins. La modification d un des utilisateurs entraine des modifications sur le modèle de tâche. Les informations sur les utilisateurs arrivant au compte-goutte, cela a entrainé de nombreux remaniements du modèle des tâches qui a rendu les modèles sous-jacents obsolètes. 3.2 Modèle des concepts Dans ce modèle des concepts, nous avons essayé de mettre en avant les principaux concepts utilisés. Ainsi, il nous a semblé évident de définir le concept d Incident et de Déclaration. Ensuite, dans un incident, nous avons retrouvé la notion de Lieu mais aussi de Photo et de Déclarant. Et enfin, dans Incident, après avoir réfléchi sur la pertinence de certaines informations reliées à l incident (cf. Causes, Intervention, Actions_Effectuées), nous avons décidé que ces informations ne concernaient pas le citoyen mais plus la prise en charge de cette incident par l administration. Le résultat est présenté ci-dessous. Fig. 2 Modèle des concepts
Télé-Procédure de Gestion d Incidents : Spécifications et Prototype. 10 3.3 Maquettes Afin de préparer au mieux le prototype, nous avons décidé de mettre en places des maquettes de l interface finale. Les maquettes représentent pas moins de 20 écrans différents pour chaque utilisateur. Ci-dessous un exemple d un écran qui représente le résume de la télé-procédure avant de finaliser celle-ci. Fig. 3 Exemple d'un écran d'une maquette
Télé-Procédure de Gestion d Incidents : Spécifications et Prototype. 11 4 Prototype Cette partie est fortement incomplète car il reste encore 2 mois à mon stage mais je vais essayer de donner au mieux les parties achevées et celles qui restent à effectuer en gardant à l esprit que les exigences pour un utilisateur donné sont encore sujettes à modification.. Géolocalisation : Interface : GSM GPS Plan Finale Fonctionnalités : Sauvegarder une procédure Créer une procédure Prendre une photo Annoter un plan Charger une procédure enregistrée Ajouter un commentaire audio Envoyer une procédure Transférer sur une autre plate-forme Identifier un utilisateur Sélectionner parmi les incidents déjà déclarés à proximité
Télé-Procédure de Gestion d Incidents : Spécifications et Prototype. 12 5 Conclusion Pour conclure, ce stage m a apprit beaucoup de choses et va continuer à m en apprendre jusqu'à fin aout. Il m a apprit qu un projet ne se bâtit pas en un jour, que chaque personne dans un projet a une place prépondérante. Du côté technique, j ai appris comment effectué une géolocalisation en utilisant les dernières technologies présentes sur téléphone (GSM, GPS), à rechercher une solution sur un problème donné (Affiner la position GSM).
Télé-Procédure de Gestion d Incidents : Spécifications et Prototype. 13 6 Remerciements Je tiens à remercier Gaëlle Calvary et Audrey Serna pour m avoir donné la possibilité de rejoindre ce projet qui m a énormément apporté au niveau de mes compétences mais aussi d un point de vue humain. Je tiens à remercier également Florence Pontico pour avoir effectué tous les entretiens avec les utilisateurs de la région Midi-Pyrénées (les utilisateurs Métier) mais aussi toute l équipe IIHM pour m avoir accueilli en leur sein.
Télé-Procédure de Gestion d Incidents : Spécifications et Prototype. 14 7 Annexe I : Modèle des tâches 7.1 Télé-déclarer des incidents 7.2 Déclarer un incident
7.3 Décrire l incident Télé-Procédure de Gestion d Incidents : Spécifications et Prototype. 15