Développement d'application Web dans un SI

Bonjour à toutes et à tous.

J'ai eu une discussion avec avec mon supérieur concernant la stratégie de développement d'applications web en interne.
Pour vous mettre dans le contexte, le Système d'information est a 90-95% Microsoft et tous les postes de travail sont Windows 8 + IE10 ( + de 1000 postes).
Tous les développements Web sont réalisé en Java.

Voila pour le contexte...

Pour en revenir aux applications web, j'ai abordé les thèmes suivants avec mon supérieur :

1 - Compatibilité multi-navigateur
Mon responsable estime que la compatibilité multi-navigateur importe peu, dans son esprit tous les postes utilisateurs ont IE et il n'est donc pas nécessaire de faire des "efforts" pour de la compatibilité multi-navigateur car nous maitrisons tous les postes et que ça engendrerait des couts supplémentaires de faire de la compatibilité.
Nous exposons certaines applications sur l'extranet à nos clients et la question de la compatibilité multi-navigateur se pose. Là encore la réponse de mon responsable a été simple et direct, "Nous imposerons IE à nos clients."


2 - Charte graphique
Nous avons fait appel a un prestataire pour qu'il nous fasse un charte graphique et une maquette Html réutilisable pour l’ensemble de nos applications web.
Il y a peu de temps un prestataire a réalisé une appli métier mais n'est pas respecté entièrement la charte graphique.
Réponse de mon responsable : "Ce n'est pas important , c'est une application métier, il n'est pas nécessaire qu'elle soit parfaite graphiquement, les utilisateurs ne sont pas là pour admirer l'application mais pour travailler"

Vous l'aurez compris, je suis en désaccord avec ces deux points.

Je souhaiterais connaitre vos points de vue sur ces sujets.

Merci.

Point 1)
Je suis à moitié d'accord, vu les information. Pour les applis purement internes, la compatibilité multi-navigateur est un coût non négligeable. Par expérience, dès que t'as un peu de javascript, et du css avancé, ça deviens même très vite une galère :mouarf:. Si tous tes postes sont sur IE, le surcoût n'est pas justifiable en l'état. Il le sera peut-être dans le futur si on envisage une migration vers un autre browser, mais pas maintenant.
Par contre, l'idée d'imposer IE aux clients.... Comment dire. J'espère qu'on est pas client chez toi car, avec ~50% de nos postes sous linux, on va avoir du mal à lancer IE :aie:. Là t'as peut-être une carte à jouer en faisant un inventaire de tes clients et de leur OS. C'est facile, ça peut se faire avec les logs des applications déjà utilisées par vos clients ;)

Point 2)
Entièrement d'accord. Une application métier utilisée en interne n'a aucun rôle commercial. La partie charte graphique est donc difficilement justifiable. Attention que la partie respect du bon sens au niveau des UI garde tout son intérêt. Autant on s'en fous que le menu soit en Arial ou en Times, ou que le logo soit à gauche ou à droite, autant il est important que les alertes restent en rouge, que les checkbox ne se comportent pas comme des radio box, sinon tu va être deux fois plus lent à utiliser l'interface :aie: L'application doit faire son métier efficacement et ne pas perturber les utilisateurs.
Pour dire les choses simplement, quand tu fais venir un plombier, tu t'en fous que sa clé à molette soit en acier chromé ou rose et jaune. Par contre, si il commence à devoir démonter tes tuyaux avec un tournevis plutôt que la clé à molette, c'est un problème.

Bonjour tchize_,

Merci pour ta réponse.
Un complément d'informations, j’entends par multi navigateur, IE9+ et une version "acceptable" des principaux navigateurs du marché.
Pour ma part, je pense qu'avec ces contraintes il n'est pas plus couteux de faire du multi navigateur (dans le cas d'une nouvelle application).

Concernant l’aspect Charte graphique, la charte a été spécifiquement réalisé pour de l'applicatif donc aucune fantaisie de ce coté la, juste un design propre et épuré.
Dans mon cas il est question de mise en forme différentes de liste d’éléments ou de boutons représentant une mémé action ( enregistrer, annulé , importer ect ...)
La mise en forme pouvait être différentes d'une page a l'autre ce que je trouve pas terrible.

je pense que lorsqu’on fait une appli il faut penser aux utilisateurs qui l'utiliseront au quotidien, cela facilitera son adoption.

Citation:

---

Envoyé par M_Makia

j’entends par multi navigateur, IE9+ et une version "acceptable" des principaux navigateurs du marché.
Pour ma part, je pense qu'avec ces contraintes il n'est pas plus couteux de faire du multi navigateur (dans le cas d'une nouvelle application).

---

Par expérience, ça peut être couteux. Car
-> tu es obligé, inévitablement, de tout tester avec tous les navigateur, sinon, comment saura-tu que c'est "acceptable" ?
-> tu tombera probablement à un moment ou un autre sur un petit truc fondamentale qui ne marchera pas sur un navigateur, ce qui te fera perdre énormément de temps. Pour prendre un exemple, j'ai ici une appli web "seulement firefox supporté". Les autres navigateurs en "best effort". A un moment on a du dire "IE, c'est fini" car la dernière version de IE ne gérait pas correctement les uploads sur un de nos formulaires et trouver une solution à ce problème aurait pu nous prendre plusieurs semaine.
-> Si tu fais sous traiter (ce qui visiblement a l'air le cas chez vous), comment tu définis "acceptable" dans le cahier de charge? Le forunisseur, inévitablement, va te facturer ces tests supplémentaire. Ne serait-ce que par sécurité pour lui.

Citation:

---

Envoyé par M_Makia

Dans mon cas il est question de mise en forme différentes de liste d’éléments ou de boutons représentant une mémé action ( enregistrer, annulé , importer ect ...)

---

Dans ce cas, ce n'est pas un problème de charte graphique pour moi, c'est un problème d'utilisabilité. Si tous les boutons étaient rond et bleu et que tu les as demandé vert et carré. Bof. Mais si une fois c'est vert et carré et une autre c'est rond et bleu, c'est une problème, effectivement.

Citation:

---

Envoyé par M_Makia

je pense que lorsqu’on fait une appli il faut penser aux utilisateurs qui l'utiliseront au quotidien, cela facilitera son adoption.

---

Oui, mais il faut, et c'est dur, apprendre à faire la distinction entre ce qui facilite le travail de l'utilisateur et ce qu'on pense logiquement lui faciliter le travail. Est-ce que tu as concrètement du retour d'utilisateurs / groupe test te disant "ça, c'est pas bien pour nous travailler parce que XXXXX"

Citation:

---

Oui, mais il faut, et c'est dur, apprendre à faire la distinction entre ce qui facilite le travail de l'utilisateur et ce qu'on pense logiquement lui faciliter le travail. Est-ce que tu as concrètement du retour d'utilisateurs / groupe test te disant "ça, c'est pas bien pour nous travailler parce que XXXXX"

---

Il y a eu des retours d'utilisateurs sur d'autres applicatifs qui mettaient en évidence des soucis d'ergonomies et de design.
Beaucoup d'utilisateurs ne comprennent pas qu'il y est un tel décalage entre ce qu'ils ont l'habitude de voir sur le web et leurs applications web interne.
Il ne prennent pas plaisir a travailler avec leurs outils et dans certain cas cela pose des problèmes de productivité.

je suis convaincu qu'un environnement de travail (de manière générale) peu influer de manière positive ou négative sur le productivité d'une personne, c'est pour cela que je défend ce point de vue.

Je te remercie beaucoup pour ces échanges :) !

La discussion est interessante et de ce que je vois côté utilisateur :

Point 1 :
Imposer un navigateur aux clients c'est plus que bof, pourquoi dans ce cas faire du web client ? Cela perd de son intérêt. J'ai déjà vu des cas ou une appli web client ne fonctionnait qu'à partir de IE9 mais les postes avaient aussi une version de BO qui ne fonctionnait pas avec IE9... Que faire dans ces cas la ? Vu qu'une petite entreprise n'a aucun poids face à un gros éditeur comme BO ( pour réclamer rapidement une mise à jour ), ils ont été obligé d'installer un second windows sur les poste en le virtualisant pour pouvoir utiliser des versions différentes d'IE... :calim2::calim2::calim2:

Et ce cas la, je l'ai vu dans de nombreuses entreprises, ce n'est pas un cas isolé.

Point 2 :
Je rajouterai aussi que si la productivité est importante, par exemple pour une appli ou l'on ne saisit que des informations, le plus important est l'enchainement de saisie de ces informations pour ne pas faire perdre du temps à l'utilisateur, mais il est vrai aussi qu'il doit y avoir une certaine cohérence dans l'affichage de l'ihm.
Pour le problème de mise en forme que tu soulignes, cela me parait important car cela peut effectivement affecter la productivité, cela peut facilement dérouter l'utilisateur.

Ces points méritent d'être débattu en effet et moi-même je suis un peu dans le même cas de figure que toi parfois M_Makia.

1 - Compatibilité multi-navigateur

Comme le dit free07, attention à la compatibilité d'un même navigateur mais dans différente version. Car savoir imposer IE à son client c'est une chose (déjà un peu autoritaire) mais savoir imposer en plus la version précise que vous utilisez, s'en est une autre. Et si les rendus n'ont pas été pensé pour être compatible à l'origine, bonjour la galère pour s'adapter après coup.

Sinon pour le côté compatibilité autres navigateurs, c'est vrai que c'est un plus mais que c'est souvent galère. Les désavantages étant que ça coûte plus en développement et que ça coûte également plus en tests (il faut vérifier cette compatibilité sur toutes les fonctions de l'application). Donc vu le taux d'utilisation d'IE par les clients en général et vu que votre parc est sous IE, il va être difficile de trouver les arguments pour gérer la compatibilité multi-navigateur.

2 - Charte graphique

J'ai l'impression qu'il y a deux points évoqués dans la réponse de ton chef : le style et l'ergonomie. Autant "le style n'est pas beau" est un argument qui peut être difficile à défendre, autant l'application manque de cohérence graphique et de facilité d'utilisation, c'est un argument important. Et ce deuxième argument impact directement la productivité d'un utilisateur puisque ça jouera sur sa capacité à trouver les bonnes fonctions et à savoir les utiliser correctement.

Je vois souvent des applications internes qui se basent sur les mêmes principes : design pas trop recherché et charte graphique simpliste. Eh bien souvent en voulant faire des économies là dessus, on se retrouve avec des applications difficiles à utiliser juste parce que l'ergonomie n'est pas du tout recherché. C'est donc un vrai calvaire à utiliser et une vraie perte de temps.

Dans les projets que vous avez pu réaliser, consacrez-vous un budget particulier pour tout ce qui concerne l'ergonomie et le design ?
Si oui , avez un idée du cout que ça représente sur la totalité d'un projet ?
Si non, comment vous vous organisez pour que la charte graphique et l'ergonomie de parte pas dans tous les sens ?

Merci pour vos réponses :) !!!