Choisir une plateforme e-commerce, c’est tout sauf simple.
On parle ici de solutions e-commerce pour des projets relativement importants, inadaptées aux solutions « tout en un SAAS » du marché.
Il n’y a ni solution miracle ni solution universelle.
Alors, comment s’y retrouver ?
Commençons par les mauvaises raisons, c’est le plus facile ;).
Les mauvaises raisons
Nombre de tables dans la base de données
J’ai entendu un commercial me présenter sa solution, en mettant en avant, comme un critère, le nombre de tables.
Plus il y a de tables, plus la solution est complexe : ça c’est sûr. Après, on peut imaginer qu’il y a beaucoup de tables parce que la solution est riche… Mais il peut y avoir beaucoup de tables parce que la solution n’est pas très bien conçue.
La capacité qu’à une solution à résoudre une problématique donnée
Vous demandez à l’éditeur si la solution sait remplir telle fonction. La réponse est toujours : « oui ».
Le commercial est il un baratineur ? Pas forcément !
En informatique, on peut toujours faire les développements pour adapter une solution à la demande.
Les raisons « pas forcément si bonnes que ça »
Qualité des interfaces des sites en lignes
On peut se dire qu’on va pouvoir juger une solution en observant comment sont réalisées d’autres boutiques.
C’est vrai que ça permet de voir certains aspects d’une solution… Mais pas tant que ça :
Les solutions professionnelles peuvent complètement être adaptées aux besoins et demandes de chacun.
Donc, ce que vous voyez, c’est avant tout la réalisation pour un site donné.
Les temps de réponses sur un site en ligne
Là aussi, ça peut sembler une bonne idée.
C’est un signal intéressant, si la plupart des boutiques motorisées par une solution donnée ont des problèmes de temps de réponses.
Par contre, la performance d’un site dépend de beaucoup de facteurs… Vraiment beaucoup : la conception des pages et leurs poids, l’utilisation ou non d’un système de cache réseau, la puissance des serveurs mis en œuvres, la bande passante achetée chez l’hébergeur, la bonne ou mauvaise configuration des serveurs…
Vous pouvez avoir une solution qui n’est pas très performante, mais qui est mis en œuvre par un pro de ces problèmes là : la solution peut répondre rapidement… Mais ça va coûter cher.
A l’opposé, vous pouvez avoir une solution qui est plutôt bien faite, mais qui est mise en œuvre « avec les pieds », et là, vous vous direz : cette solution, elle rame… Alors que le problème ne vient pas de là.
Richesse fonctionnelle
On peut imaginer qu’il est beaucoup mieux d’avoir une solution très riche fonctionnellement.
Oui et non… La solution e-commerce doit être excellente sur son cœur de valeur : gestion du catalogue, des processus achat, …
Après, pour certaines fonctions, si on veut être très performant, on a sans doute intérêt à assembler les meilleures briques du marché : Searchandising, CRM, …
Donc, pour un projet ayant une certaine taille, il vaut mieux un cœur fonctionnel super bien fait plutôt qu’une solution qui « fait tout » mais qui est moins bien conçue.
Le prix
Le prix est évidement à la base une excellente raison !
Le problème, c’est que pas mal d’éditeurs ont un peu de mal à proposer un prix simple et lisible.
Autre point, pour un site, ce qui compte, c’est bien le prix total, intégration comprise. Si une solution n’apparait comme pas trop cher à la licence, mais que l’intégration coûte les yeux de la tête, c’est pas forcément un bon deal…
Les bonnes raisons
La qualité de conception de la solution
C’est un facteur très important : une solution bien conçue sera plus facile à faire évoluer, il sera plus simple de corriger les problèmes, plus facile de trouver des développeurs… Bref, la vie sera plus facile.
Le problème, avec ce critère, c’est qu’il demande une analyse très fine de la solution pour savoir si le cœur est bien conçu ou non.
Une solution très appréciée par les utilisateurs
Une solution qui est très appréciée par ceux qui l’utilisent, c’est un point très positif.
Il faut faire ce travail, de prise de référence, très au sérieux. Pour avoir un avis complet, il faut pouvoir discuter avec plusieurs interlocuteurs : responsable, équipe technique, … Chacun a un point de vue par rapport à la solution, et c’est la « compilation » de ces interviews qui permet de se faire une réelle bonne idée sur la solution. Autre point à prendre en compte : quand un décideur a choisi une solution, il n’est pas forcément dans la position d’expliquer qu’il c’est trompé…
Alors, on fait comment ?
Ce qui est sûr, c’est qu’au minimum, on prend des références sur la solution présenti.
Si on a le temps, c’est une très bonne chose que de « soulever le capot » et de regarder un peu comment la solution est réellement réalisée.
Si on n’a pas le temps, on peut se tourner vers des spécialistes !
Enfin, et je n’insisterais jamais assez sur ce point : le choix de l’intégrateur est finalement bien plus important que le choix de la solution. C’est avec lui qu’il faudra vivre pendant plusieurs années (normalement 😉 ). Il doit faire du bon travail, des développements de qualités.
C’est fondamental, mais c’est pas si simple (non plus) à qualifier… Mais ça sera l’objet d’un autre billet !
La pérénitée de la solution choisie est egalement un critère important à prendre en compte.
Pour l’histoire du nombre de tables, il s’agit parfois de techniques d’optimisation consitant a eclater les tables pour des questions de performance, donc un travail d’analyse plutot complexe et fastidieux.
Pour la qualité du code, on peut prinipalement se focaliser sur le ou les frameworks utilises et methodes de conception, afin que les developement specifiques supplementaires ne coutent pas un bras a l’ecommercant, ni des cheveux aux developpeurs.
Ah bien d’accord avec cet article.
@Alex peut-être mais pas forcément non plus.
Le coup des tables ça m’étonne même pas. Parfois certains comptent le nombre de lignes de code aussi …
ça peut être un signe de richesse fonctionnelle mais aussi de code mal factorisé …
Bref ce ne sont effectivement pas des critères valables dans le choix d’une solution si on analyse pas plus loin.
Petite précision sur le temps de réponse. Le délai de génération de la page html peut-être un bon indicateur s’il est pris régulièrement. Mais attention à ne prendre pas que le code html, pas les images et autres css/javascript.
Je suis étonné de vois qu’un client « final » se pose la question du nombre de table, par contre un consultant un peu plus 😉
Un bon indice à ce niveau de la qualité du code est la position des index sur les tables. C’est très technique de placer les bons index aux bons endroits pour optimiser la vitesse en lecture, sans dégrader l’écriture.
Quand au design, un site beau n’est pas forcément efficace. Et un client peut avoir des goûts étranges et la solution s’adaptera …
Ce choix n’est jamais simple, de toutes façons. Chaque solution a ses avantages et ses inconvénients… le bon principe est de partir du besoin précis au jour du lancement et d’être capable de projeter les besoin à terme, histoire de voir si la solution peut « suivre », sinon… ben sinon on est dans la merde, comme on dit techniquement, voire « in deep shit » si on veut se la jouer « je cause angliche ».
Un site ecommerce repose avant tout sur la technique, mais à partir de là on se préoccupe du reste qui devient le plus important : est-ce que ma solution répond techniquement aux besoins, après comme dit Maxime, « la solution s’adaptera » d’un point de vue ergonomie, mise en page et graphisme.
@François : ce serait bien de pouvoir suivre les commentaires en étant alerté par mail, tu n’as pas cette fonction ?
@François> Pour ta dernière question, ce blog tourne sur WP. Il doit bien y avoir des plugnins pour gérer ça… Tu peux me conseiller 😉 ?
C’est sur qu’il faut bien étudier la question avant de se lancer, parce que changer après est loin d’être simple.
Pour moi les critères ont été le prix, la modulabilité et la communauté. J’ai opté pour une solution libre et gratuite.
@François> Olivier Gobet, qui gère ce blog pour les aspects technique, a mis en place le plug in. Merci pour la suggestion !