LunaWeb présente : L'extranet assurés Thélem assurances :
le making-of du point de vue d'une petite agence web.

C'est l'une de nos plus belles réalisations de l'année 2010, tant elle nous a offert l'opportunité de pousser les savoir-faire de l'agence dans ses retranchements. L'ergonomie, le design, la gestion de projet, l'intégration HTML/CSS ont été éprouvés à des degrés très élevés, et nous remercions pour cela Thélem assurances de la confiance qu'elle a bien voulu nous porter.

Nous vous souhaitons une bonne lecture.

Le pitch du projet était clair : faire entrer cette marque bien installée dans l'ère de l'extranet pour la gestion de sa relation client, sans rien entamer du positionnement de Thélem assurances, toujours au plus près des préoccupations de ses assurés, et soucieuse maintenir ce rapport de proximité, cette "dose d'humanité", qui fait la différence à l'heure de choisir une compagnie d'assurances.

La mise en œuvre d'un tel projet supposait une longue phase de réflexion, de définition des objectifs et des besoins, de faisabilité technique et financière. Nous avons eu la chance d'être partie prenante dès la genèse du projet, par la réalisation des maquettes primitives (le prototype) de cet extranet naissant.

Concevoir une charte pour l'extranet

Mis en compétition sur la seconde phase du projet, la partie opérationnelle (audit ergonomique, wireframing, maquettage graphique et intégration HTML), nous avons commencé par définir les bases de l'interface web appelée à recevoir de nombreux services de gestion d'un compte client assuré en ligne.

Retenus à l'issue de cette consultation, nous avons rencontré tous les acteurs du projet (en interne et en externe) afin de réunir un maximum d'éléments nous permettant de cadrer le projet. Partis d'une charte de communication "classique" (fournie), nous avons alors réfléchi à la possibilité d'une charte spécifique à l'extranet, dont les objectifs de compréhension et de navigabilité nous orientaient vers une solution dédiée.

À droite, la page d'accueil du site thélem "publique",
notre base de réflexion graphique.

Sans rien renier du design du site public www.thelem-assurances.fr, nous avons donc planché sur une adaptation des codes visuels (éléments d'interface, couleurs, fontes, ...), puisqu'il est établi qu'un extranet est avant tout un outil et pas un media. Il doit donc s'adresser avant tout à l'utilisateur final (ici : l'assuré), et viser à son entière satisfaction. En l'occurrence, l'internaute doit trouver l'information, vite et simplement, et réaliser les opérations de base de l'administration de son compte.

Cette tâche doit tenir compte de nombreuses contraintes, dont celle de pouvoir proposer des opérations techniquement réalisables pour les services métiers. Forts de nos expériences extranet réussies, nous avons pu capitaliser et proposer des modèles d'interfaces efficaces répondant aux besoins d'un utilisateur :

envoyer un message,
valider une adhésion,
calculer un taux de remboursement,
ou encore commander une attestation.

Ce kit à l'usage des développeurs permettait, déjà, de bénéficier d'un référentiel graphique et technique permettant de se projeter sur les actions complexes consignées dans nos scénarios utilisateurs.

Une fois validée cette étape de faisabilité, il convenait alors de projeter nos scénarios utilisateurs dans la vraie vie, c'est-à-dire réaliser tous les écrans ergonomiques de toutes les phases d'une visite sur cet extranet. Autant dire, quelques centaines d'écrans à maquetter...

À gauche, un aperçu de la charte graphique.

Penser l'ergonomie pour l'extranet

Ce long travail fait d'échanges avec le client et de nombreux ateliers réunissant divers acteurs du projet (développeurs, responsables métiers, experts utilisateurs, etc.) nous a permis de matérialiser le fonctionnement de chaque opération de gestion d'un compte assuré.

Tests après tests, nous avons raffiné les wireframes (ébauches de maquettes) jusqu'à obtenir le compromis idéal pour une utilisation rapide et simple.

Évidemment, il faut parfois composer avec LA contrainte technique qui met par terre le bon concept et qui suppose de repenser entièrement la logique de l'opération en cours. Depuis la connexion utilisateur en page d'accueil jusqu'au moindre retour d'erreur d'un formulaire "profond", il convenait de veiller à la logique des choses, au nombre de clics permettant d'accéder à telle action, au ton employé dans les instructions, aux retours en arrière possibles, au design de chaque nouvel élément qui doit rentrer dans une charte visuelle homogène et signifiante.

Conscients du contexte extranet très particulier, supposant côté développeur de nombreux tests, et côté client un besoin de "voir en vrai" le résultat de nos études ; nous avons choisi de travailler assez rapidement de manière conjointe sur deux fronts :

la réalisation des maquettes ergonomiques, étape par étape,
la conception des maquettes graphiques, avec un très léger décalage (le temps de valider la phase ergo).

Cette grande souplesse offerte au client suppose d'être capable de mobiliser différents profils simultanément (chef de projet, ergonome et webdesigner), mais elle permet de balayer très rapidement toutes les phases d'une opération (ex. : éditer un RIB) sur le plan commercial (le client), technique (le prestataire de dév) et fonctionnel (l'agence de webdesign).

À noter que le nombre d'écrans à produire explose très vite, chaque version de chaque type d'écran doit être consignée et numérotée pour rapidement permettre aux acteurs de valider/corriger telle maquette et pas sa voisine.

Chaque état, chaque survol, chaque retour d’erreur fait l’objet d’une maquette.

Avec le recul, notre système de dossier par date et par numéro de maquette (ex. : accueil-actionXYZ-date-versionnum.jpg) s'avère vite insuffisant, et potentiellement générateur d'erreur.

Un outil en ligne tel que Notable nous semble, pour ce cas précis, beaucoup plus simple pour un retour client précis, exploitable et infaillible en terme de version de page.

Au final, ne souhaitant pas changer de système en cours de route (c'est la pire des choses à faire selon moi), nous sommes partis sur le principe d'un tableau Excel composé de plusieurs colonnes dont le nom exact du fichier, les commentaires client, les commentaires développeurs et nos observations. Un peu lourd en fin de course, mais fiable.

Réaliser le templating HTML

Nous sommes une agence de conception d'interfaces web, il est donc très naturel pour nous d'accepter de nous arrêter avant la réalisation complète d'un site, qui plus en est en contexte extranet pour des structures comptabilisant près d'un demi-millions de clients...

Zoning : Définir les portlets Java, et créer les boîtes HTML/CSS qui y correspondent.

Dans ce genre de situation, autant bien s'entendre dès le début avec les différents acteurs du projet, à commencer par ceux qui vont assurer le développement du système... Ce sont des technologies lourdes, massives, pas toujours dans nos standards en terme de propreté du code, mais enfin les problématiques sont différentes et les enjeux imposent ce genre de solutions.

La gestion des erreurs, selon quelle info remonte du système.

Si nous ne sommes pas des experts en J2EE ou en DotNet, il nous est cependant nécessaire de comprendre comment ces environnements fonctionnent afin de capter les spécificités et les limites imposées. En se mettant d'accord dès le début sur le type de librairie javascript employée ou encore les règles HTML/CSS "qui passent" et celles qui bloquent, on propose au client des maquettes HTML qui seront effectivement réalisables en bout de chaîne. C'est la moindre des choses, mais cela suppose de faire des efforts...

À droite, l'arborescence du projet et le détail du HTML produit.

La première étape des spécifications étant acquise, il vous reste à réaliser un master HTML, par exemple un état de la homepage, afin de s'enquérir de la réaction des développeur face à votre matrice. Vous devrez bien-sûr retoucher votre création sur de nombreux points pour réussir à obtenir le sésame, mais au final cette première base va vous servir tout au long d la réalisation des autres écrans.

Comme l'extranet permet de faire beaucoup de choses, que l'utilisateur a la liberté de se tromper et de recommencer, et qu'il faut offrir un maximum de niveaux d'informations dans un minimum d'espace ; il convient de toujours prendre un temps de réflexion entre la validation de la maquette graphique et l'édition HTML de cette page :

la chronologie des étapes antérieures trouve-t'elle une suite logique dans cette action ?
comment la page va-t'elle se charger ? dans quel ordre ?
l'utilisateur non-averti comprendra-t'il ce qu'on lui demande ?
les libellés sont-ils appelés à être modifiés ?
les champs de saisie sont-ils suffisamment longs pour abriter un nom de famille composé ou à rallonges ?
ce script d'attente est-il réalisable compte tenu du contexte de lightbox dans lequel on se situe déjà ?
comment revenir en arrière si je viens de réaliser une action et que je n'ai pas le retour d'informations de mon système me permettant de lui afficher un résultat concret ?
que dois-je faire si mon webservice tombe en panne à cette étape du formulaire de commande ?

Bref, la vraie vie d'un intégrateur HTML soucieux de l'utilisateur lambda qui ne se posera alors qu'une seule question : "Mais pourquoi ça marche pas leur truc ?".

Conclusion

Ci-dessus, trois des nombreuses itérations qui composent le design d’une page.

Après 4 mois d'efforts intenses, nous touchons au but. L'organisation-projet basée sur le processus itératif et la validation à divers niveaux permet à chaque nouvelle grande partie du site de capitaliser sur les précédentes étapes, et de construire ainsi un portail logique, fonctionnel et homogène.

Au final, notre expertise ergonomique aura servi à définir les services à proposer au client, les maquettes graphiques auront conduit les options d'interfaces offertes à l'internaute et le templating HTML aura permis de s'assurer que les développements permettraient une expérience utilisateur satisfaisante.

Ce type de projet d'envergure ne saurait être lancé sans des tests utilisateurs dans la cible même du site. Nous allons donc entamer la dernière phase du projet, celle de l'épreuve du feu, permettant de finaliser les éléments d'une interface et répondre à des questions du type :

mon libellé d'action est-il suffisamment explicite ?
quand j'invite à la saisie des champs de mon RIB, est-ce compréhensible ?
le tunnel d'achat est-il bien perçu ?
mes pictos sur les informations de paiement sont-ils rassurants ?
le message d'erreur génère-t-il autant de corrections que voulu ?
mes boîtes de dialogue sont-elles suffisamment suggestives ?
...

En qualitatif et en quantitatif, l'entretien avec un utilisateur habitué de la marque mais n'y connaissant a priori rien du contexte extranet, nous permet de mettre nos théories sur le grill, pour le meilleur au final puisqu'il s'agit de produire une interface la plus claire et efficace possible.

On fait vraiment un métier formidable...

Crédits