Si je continue comme ça, je vais faire des articles complets juste avec un titre 😉
Quand on compare les solutions e-commerce, on peut « attaquer » le sujet sous plusieurs angles.
La première idée, c’est de regarder des sites existants
Sont ils bien fait ?
Les processus sont ils bien conçus ? Process achat, compte, … ?
Et les temps de réponses, le traitement des erreurs, ?
Bref, regarder des sites existants permet de se faire une première impression.
Attention ceci dit, à ne pas juger sur l’aspect graphique : la plateforme e-commerce n’est pas responsable du travail des designers des différentes boutiques.
Deuxième idée, le back office
C’est pas mal, et riche d’enseignement, que de regarder ce que propose le back office d’une solution.
Cela permet de mesurer sous un autre angle la richesse fonctionnelle de la solution, et son niveau de paramétrage.
Troisième idée : appeler des références
toujours une bonne idée, que d’appeler des utilisateurs d’une solution.
Cela permet d’avoir un retour d’expérience.
Bon, attention, les retours ne sont pas toujours complètement neutre, et puis, il est souvent difficile pour l’égo, et pour la tranquilité dans son job, de remettre en question le choix q’on a fait… il faut donc relativiser les retours que l’on obtient.
Quatrième idée : la converture fonctionnelle
Au delà de l’analyse front et back, on peut (on doit) faire une analyse fonctionnelle, et voir ce que couvre la solution.
Hum, c’est bien sûr très bien, mais, contrairement aux apparences, ce n’est pas si simple que ça :
Comment identifier les fonctions clés ?
Comment savoir si une fonction est réellement dans la solution ou pas ? Les éditeurs de solutions ont des équipes marketing, et toutes les solutions affichent savoir tout faire…
Et puis, si une fonction est absente, mais facile à ajouter, est-ce important si la fonction n’est pas nativement présente ?
Cinquième idée : l’analyse technique
Nous y voilà.
Doit on faire une analyse technique avant de choisir une solution ?
Et que doit on chercher « sous le capot » ?
La qualité de conception, la qualité du code, cela aura un impact sur :
- La robustesse de la solution : sa capacité à bien résister à des cas « hors limite ». C’est fondamental pour le web
- L’évolutivité de la solution : sera-t-il compliqué de faire évoluer la solution ? Si la solution est « un plat de nouille », il sera difficile de faire évoluer le truc…
Vous l’aurez compris, à mon avis, oui, il est fondamental de faire cette analyse technique, et c’est pas forcément si facile, quand une solution n’est pas open source…
Maintenant, si vous êtes sur un petit projet, et que vous ne comptez pas « customiser’ tant que ça la plateforme, ce n’est pas nécessaire de pousser cette analyse.
Bonjour,
Nous pourrions également compléter cette petite liste par le fait de vérifier si une communauté de développeurs est active, nombreuse et réactive!Cela permet d’obtenir un bon support en cas de problème.
Autre point à regarder, le nombre de plugins et la fréquence des mises à jour.
Ces points sont valables dans le cas d’une solution open-source bien sûr..
Dans le cas d’une solution « en propre », il faut également regarder si le SEF est bon. Certaines solutions développées proposent des URL qui ne sont pas re-écrites et loin d’être « google friendly »!
Voir également si les basiques du SEO sont en place: des title sur les liens, des alt sur les images, des balises H1/H2/H3 etc etc!
Tu oublies le prestataire. C’est difficile pour ceux qui commencent à faire du developpement mais je partirais avec un prestataire qui a déjà fait qqch de bien.
Quand j’ai découvert l’excellent site de archiduchesse.com j’ai également regardé qui était derrière. Et Axiome semble une bonne référence 🙂
Je suis d’accord avec vos commentaires.
En fait, je voulais surtout poser la question de l’analyse technique (d’ou le titre). Mais j’ai généralisé au fil de l’écriture, et donc vous avez raison, pour le coup, il manque des critères 😉
Merci François pour ce rappel, j’ai une petite idée de ce qui t’a inspiré ce billet 😉
@Ludovic> 😉