Vous devez faire, ou refaire, un site internet ou e-commerce dans un contexte d’entreprise.
Vous vous posez, vous devez vous poser des questions, nombreuses, permettant de définir le « bon » site : organisation du site, questions sur la forme, sur le fond, …
Vous vous demandez comment faire ?
La question de la méthode est très importante. bien des entreprises ont un processus de décision, face à toutes les questions fondamentales qu’on se pose quand on fait un site, pas forcément très rationnel.
Certaines entreprises cherchent le consensus interne. La réponse aux questions clés sera cherchée quand les personnes misent dans la boucle seront toutes d’accord avec la proposition.
L’avantage de cette solution, c’est qu’on demande à plusieurs personnes…
C’est également son inconvénient : on va être dans le consensus. Le résultat choisi cera celui résultant plus d’une « négociation » que de la recherche de la meilleure solution pour les clients.
L’autre solution peut être de faire valider les choses par le boss. Hum, pour le coup, on n’est pas dans le consensus… Mais que va donner cette méthode si le chef n’a pas une culture internet très avancée ? Et puis, est-ce normal de faire décider, sur des détails d’un site, un manager, qui ne pourra y consacrer que quelques minutes, quelques heures maximum ? Ne prend on pas le risque d’une décision « à l’emporte pièce » ?
Si le site est complètement stratégique, et que le boss est hyper impliqué dans le projet, cette méthode peut avoir du sens. Sinon, elle est très risquée…
Qu’on ne se méprenne pas sur le sens de mes propos : c’est très bien de faire valider par le chef, mais il convient de poser les bonnes questions, et de ne pas faire valider des détails ou certains éléments, qui doivent être travaillées à d’autres strats.
Cela me rappel un discours, qui m’a marqué, au début de ma vie professionnelle.
Je venais de rentrer à la R&D de France Télécom. J’ai eu droit à une journée d’accueil.
Lors de cette journée, un prof de science po, dont je ne me souviens pas du nom, nous a fait un discours. Brillant le discours !
Et bien, l’élément qui m’a le plus marqué est cette phrase : « vous devez manager vos managers« .
Voilà, c’est bien cela. On ne doit pas demander n’importe quoi à n’importe qui.
Dernière solution, on demande à un expert. Un pro du domaine.
Un expert, s’il est bon, va apporter de la valeur, mais il ne peut pas répondre à toutes les questions, il ne peut pas régler tous les problèmes. Certaines questions ne peuvent être traitées que par l’entreprise.
Donc, si on ne doit ni demander à tout le monde, ni tout faire valider par le chef, et qu’on peut pas tout faire faire par un expert, on fait comment ?
Bonne question !
La bonne méthode est un mix de plusieurs choses.
La première chose est qu’il faut identifier et définir plusieurs rôles.
Si c’est une bonne idée de faire une équipe, pour travailler sur un sujet stratégique, ce n’est pas raisonnable de demander tout à tout le monde.
Ce point particulier demande un doigté managérial, et une certaine maturité de l’équipe. Bon, faut pas non plus se mettre trop la pression, on fait au mieux ;).
L’autre point, c’est que chacun doit faire preuve d’umilité pour faire avancer le débat avec un bon niveau de qualité.
Chacun doit donc comprendre que c’est un jeu de rôle, et chacun doit jouer son rôle.
Le deuxième point est qu’il faut définir un processus, qui devra ensuite être respecté.
Enfin, troisième point, on doit valider certains éléments via des avis utilisateurs.
Heu, mais si on n’a pas les moyens de faire des tests utilisateurs, on fait comment ?
Bonne question ;). Reccueillir l’avis d’utilisateurs, ça peut complètement se faire gratuitement. Si on n’a pas de sous, c’est très bien de mettre ses proches à contribution. S’assoir derrière sa mère, sa soeur, son oncle, sa copine, … et les laisser réagir, face à une maquette ou un projet, c’est très instructif !
On peut aussi, on doit aussi utiliser les avis des membres de l’entreprises, pris comme des utilisateurs potentiels.
Non, il n’y a pas de contradiction, on est toujours dans le jeu de rôle ! Chacun dans l’entreprise peut donner son avis, en tant qu’utilisateur. Mais, comme dans tout jeu de rôle, la hiérarchie n’est pas, dans ce jeu, celle de l’entreprise. L’avis des chefs sera pris en compten au même titre que l’avis des autres membres de l’entreprises. Pourquoi ? Mais parce que dans cette manche là, l’avis des uns et des autres a été pris en tant que personne, utilisateur potentiel, pas en tant que chef.
Mais bon, bien souvent, c’est une bonne idée d’aller un cran plus loin, et de faire de vrais tests utilisateurs !
Ce sera le sujet d’un prochain article ;).
François, je te rejoins sur la difficulté de mettre en place ou de rewamper un site. Ma propre expérience en la matière rejoint totalement ton billet. Avec quelques remarques complémentaires.
La mise en place ou le redesign d’un site qui n’a pas comme base quelques fondamentaux « chiffrés » en terme de business est souvent mal parti (une justification par exemple uniquement sur des critères purement techno est par exemple un projet souvent douloureux)
Dans la mesure ou un site web est extrement visible (ou alors y un loup 🙂 ) La DG doit être dans la boucle et en même temps pas être un bloqueur. Délicat à gérer au quotidien.
Autre point est que le cycle de validation ne doit en rien être impactant sur le cycle de developement. Dit comme ca ca semble évident, mais les boites refusent de plus en plus ce que l’on nomme des projets « Waterfall » C’est à dire des spec puis du dev puis de la recette avec un coté « effet tunnel évident » donc il est demandé de plus en plus de travailler en mode « AGILE » ou SCRUM mais en même temps souvent le patron du projet – notamment fonctionnel – veut l’aval du Boss et le boss a pas le temps, du coup vous avancez dans les SCRUMs meeting et la boum il faut tout revoir !
Quelquesoit la solution il est aussi important de bien comprendre les capacités de ce qui va être mis en place sinon le risque de faire rêver est important mais l’atterissage sera brutal. Et même avec SCRUM le prototypage rapide n’est pas toujours faisable.
Et point « credo » chez moi, ne pas se laisser illusionner par les agences de design qui font briller les yeux du responsable Marketing mais qui va demandé 100 fois plus de temps que qql chose de plus « rationnel ». Et les agences savent se montrer très « persuasives » et du coup on oublie la partie immergée de l’iceberg que tout projet eCommerce doit prendre en compte: l’intégration avec le reste du SI de l’entreprise pour une bonne efficacité de votre site.
Merci François pour cet article plein de bon sens.
Je suis bien d’accord avec toi, le processus de validation d’un site est déterminant. D’ailleurs, nous sommes comme toi 😉 chez Altics nous pensons que les tests utilisateurs sont importants. Pourquoi ? Car au final ce sont les e-shoppeurs / euses qui achètent, pas celles et ceux qui ont validé les maquettes…
Sur le prix des tests utilisateurs, je voulais préciser plusieurs choses :
– tester un site ne coûte pas cher. Cela rapporte de l’argent.
– plus on teste tôt, mieux c’est. Sur des maquettes, c’est idéal car on peut encore modifier
– mieux vaut tester peu que pas
– cela va vite
80% des grains de sables ergonomiques sont repérés par 5 utilisateurs en situation de tests utilisateurs Web.
Après on peut faire de l’Eye Tracking ou pas selon son budget 🙂
/Olivier Marx, fondateur
Altics
Le processus de création / refonte d’un site internet en entreprise est souvent source de stress pour l’équipe qui gère le projet. C’est pourquoi l’accompagnement d’un spécialiste neutre qui aiderai à trouver le bon « mix » entre validation par le boss, test utilisateurs internes, test utilisateur externe à l’entreprise, test clients et recommandation d’experts.
Il faut juste que l’équipe soit assez mature pour s’entendre dire que les solutions qu’elle propose ne sont pas toujours celles qui sont en adéquation avec les besoins réels et des fois là ça coince.
Il m’arrive d’accompagner des clients sur ces questions et il faut parfois plusieurs mois pour que l’équipe fasse le chemin pour atteindre la maturité et le recul nécessaire au bon déroulement du projet.
Merci pour cet article qui pose les bases d’une réflexion saine. A faire lire par tout ceux qui souhaitent se lancer dans le web en équipe.
Pierre