RBS Change : forces et faiblesses

J’ai passé 7 jours dans les locaux de RBS Change en Alsace dans le but de découvrir concrètement ce qu’était réellement cette solution e-Commerce, comment elle se positionne, quels sont ses atouts, quels sont ses défauts.

Il faut bien admettre deux choses : il y a énormément à dire et le sujet mérite d’être traité avec intérêt.

C’est que les pauvres chez RBS sont en train de flipper en se demandant à quelle sauce ils vont être mangés, surtout que je n’ai pas été avare en critiques lors de la formation. Qu’à cela ne tienne nous allons maintenant disséquer un peu l’animal…

1. À l’origine de RBS Change

Change n’est pas un produit qui vient du néant, développé par la société RBS, Change était à l’origine un produit close source pour les clients RBS.

Nous verrons que cet héritage influence encore le produit à ce jour, la transition vers le modèle open-source n’étant visiblement pas encore tout à fait abouti.

De l’aveu de l’éditeur il s’est fait au forceps face à la concurrence de Magento, et force est de reconnaître que nous avons en RBS Change un véritable concurrent à Magento.

Une étape importante de cette transition est la v4 de Change qui verra le jour en 2013, j’expliquerai au fur et à mesure de cet article en quoi la v4 est probablement la version stratégique de cet outil pour son adoption comme plateforme e-Commerce de manière plus généralisée.

2. Concernant l’aspect fonctionnel

2.1 Le CMS

L’une des grandes forces de ce logiciel est sans aucun doute l’aspect gestion de contenu, à ce niveau Change écrase ses concurrents en fournissant des outils intégrés qui permettront l’ajout de blocs au sein de zones délimitées à l’avance par le concepteur de la charte graphique.

On ajoute à cela un système de publication qui va fournir pour n’importe quel document du site (incluant les fiches produits et les catégories de produits), un système de prévisualisation efficace, un workflow de validation, une gestion multi-langue, des gabarits de pages multiples, et une programmation de la publication à date.

Pour éviter toute destruction en règle par les utilisateurs, Change a même dû brider son outil à la demande de ses clients, trop simple d’utilisation il aboutissait à la dérive du site façon sapin de Noël.

Depuis, le CMS peut limiter le rédacteur à des styles prédéfinis en accord avec la charte graphique du site.

On notera également des petits plus qui rendent le travail plus agréable comme le drag&drop des images depuis votre bureau jusqu’à la bibliothèque de média du logiciel.

En plus de la notion de CMS, Change embarque un certain nombre de modules CMS (hors e-Commerce) tout à fait substantiel : système d’actualités, blog, enquête, FAQ, Forums, offres d’emplois, …, leur présence permet légitimement de dire que non content d’être un CMS e-Commerce Change est aussi un CMS tout court et cela le différencie notoirement de Magento.

On regrettera tout de même que la pré-visualisation ne soit disponible que dans l’édition des pages, mais pas dans les documents qui vont se faire afficher par la page en question, par exemple il n’est pas possible de pré-visualiser un produit précis, tandis que la page fiche produit l’est, mais vide de tout produit.

RBS Change : fiche produit mode édition

Edition de l’agencement d’une page, ici seul le bloc central est modifiable malheureusement la pré-visualisation ne fonctionne pas correctement sur ce type de page.

RBS Change front office - homepage

Page d’accueil, contrairement à la fiche produit la prévisualisation est ici tout à fait fonctionnelle

Enfin on n’oublie pas la capacité multi-sites du logiciel qui ne se limite pas à la partie e-Commerce mais aussi à sa composante CMS.

Evolution v4 :

Il sera possible non-seulement d’ajouter de nouveaux blocs mais également de gérer le positionnement de chacun d’entre eux, actuellement limité à avant ou après, il sera possible en v4 de contrôler directement la sous-division de la page en sous-colonne pour placer les blocs les uns à côté des autres

2.2 Le back-office

Le back-office est malheureusement à ranger parmi les points négatifs de la solution, je lui reproche principalement 2 choses.

D’une part l’accès au back-office est sécurisé via un module Firefox, son premier défaut est donc d’imposer l’utilisation de Firefox pour l’accès au BO de Change. Quand on sait que ce module ne fonctionne pas sur les dernières version du dit navigateur et voilà que votre serviteur se retrouve obligé de downgrader son Firefox pour pouvoir utiliser Change durant la formation, puis une seconde fois pour pouvoir vous rédiger cet article…

D’autre part, même si techniquement le premier point n’est qu’une conséquence de celui-ci, l’interface BO a été faite en… XUL, je ne connais pas les raisons de ce choix mais de toute évidence il n’est pas concevable de continuer à l’utiliser, d’ailleurs Firefox abandonne le support de XUL ce qui précipite, pour mon plus grand bonheur, la migration en v4 vers une interface classique orientée web.

Nous avons donc une interface BO qui, si elle est fonctionnelle (rien à redire ça marche quand les conditions sont réunies), se trouve être absolument pas intuitive, je pourrais même être méchant en disant qu’elle me rappelle l’interface de Windows 98.

RBS Change Back Office - Synthèse

C’est… fonctionnel

RBS Change : back office

Ici, on est complètement perdu au début, il faut dire qu’on y mélange de tout, page statique, menu de navigation, catégories de produits, sans compter des icônes pas toujours représentatives (qui est capable de dire ce que signifie le cœur ?)

Evidemment je pense qu’il n’est pas la peine d’aborder la question de l’accessibilité du BO sur autre chose qu’un PC.

Malgré ça on est surpris par certaines fonctionnalités originales et vraiment pratiques ; ainsi quand le back-office est ouvert avec le front-office dans un autre onglet, RBS vous proposera via une petite fenêtre de dialogue d’ouvrir directement les éléments concernés par la page dans votre backoffice. Je ne sais pas si cette fonctionnalité sera conservée en v4.

RBS Change Front office - Fenêtre de dialogue

Certaines fonctionnalités sont vraiment pratiques

2.3 Les fonctionnalités e-Commerce de RBS Change

Sur cette section il est impossible pour moi d’être exhaustif, les capacités de RBS sont nombreuses et à chaque fois que j’ai poussé le bouchon en termes de possibilités, la solution était généralement capable de faire aussi bien sinon mieux que Magento.

Les modules e-Commerce pour RBS sont les suivants :

  • Animation des boutiques : moteur de promotion et d’animation commerciale (payant)
  • Catalogue et boutique : gestion des produits, catégories et multi-site
  • Commandes : traitement des commandes
  • Comptes clients : gestion des clients
  • Fidélisation : coupons de réductions et points fidélités (payant)
  • Gestion avancées des stocks : gestion des entrepôts (payant)
  • Gestion des retours (payant)
  • Magasins : cross canal e-Commerce / magasin (payant)
  • Gestion des marques
  • Support client (payant)
  • Ventes privées (payant)
  • Filtres et facettes : moteur de conditions et navigation à facette (payant)

Vous trouverez la liste complète des modules sur cette page.

L’un des points notable de RBS est sa composante cross-canal dédiée, en effet l’outil met à disposition des extranets magasins permettant de visualiser les commandes, les colis en attente de retour et les commandes à préparer.

Je reviendrais sur le prix des modules dans la partie modèle économique de cet article.

À titre d’exemple, je vais essayer de vous présenter les fonctionnalités de la gestion d’une boutique.

2.4 Gestion de la boutique

La solution permet de créer plusieurs boutiques, chacune d’entre-elles peut avoir un nom de domaine spécifique ou alors pointer comme un répertoire (www.votrenomdedomaine.fr/maboutique).

Il est possible de créer des filtres de livraison et des filtres de paiement sur la boutique, un moteur de condition puissant qui permet de définir avec une très bonne précision le paramétrage des filtres.

Les rayons (comprendre les catégories de produits) vont principalement servir à ranger les produits, en dehors du fait qu’ils puissent être affectés à des magasins chaque rayon détermine également les facettes disponibles pour l’internaute. On appréciera le fait qu’on puisse appliquer une charte graphique spécifique à un rayon via le CMS.

Enfin il y a les produits, de 5 types différents, ils permettront entre autre de gérer des produits simples mais également les lots de produits en passant par les variations de produits et les produits téléchargeables. J’ai particulièrement noté le fait que dans les produits composés comme le kit, on puisse y mettre des produits à variation ce qui n’est pas possible chez la concurrence (Magento !). La gestion des prix est très complète et n’a rien à envier aux autres solutions avec des prix à dates, des prix par groupe tarifaire ou des prix par client, le tout en multi-boutiques bien-sûr. En outre, la solution est capable de gérer les liaisons entre les produits pour les mises en avant marketing. Certaines fonctionnalités importantes sont toutefois absentes : pas de personnalisation des produits, pas de limite en nombre maximum dans le panier.

2.5 Divers

J’ai relevé certaines particularités, la réservation des stocks se fait dès la mise au panier (15 minutes renouvelables) malheureusement cet aspect est gâché par le fait que le nombre maximum de produits par ligne panier n’est pas limitable.

PhPTal présente à minima au moins un avantage : l’impossibilité d’y mettre du PHP évitera aux développeurs de tomber dans la facilité comme souvent avec Magento où des traitements sont mis dans les vues.

La gestion d’un thème s’accompagne d’une bonne idée. Le nom des fichiers est suffixé par deux identificateurs compris par Change et permettant d’indiquer si le contenu du fichier convient à un navigateur précis ; en suffixant par exemple avec « all.all » cela signifiera tout navigateur, toute version, tandis qu’un « ie.all » indiquera, Internet Explorer, toute version. Quand on connait la difficulté à maintenir une compatibilité entre les navigateurs, on sait que la séparation est un choix qui offre de bons résultats ; Magento avait commencé à emprunter ce chemin mais cela se limitait à l’insertion des CSS et Javascript.

Une autre bonne idée est le fait que la gestion CMS permette de déterminer des styles pré-définis pour le WYSIWYG du Back-office, les utilisateurs alors restreints (ou pas) à cette liste sont assurés de ne pas transformer leur site en « sapin de noël ».

3. Concernant le code

3.1 Architecture de base de RBS Change

RBS Change a une architecture complexe, techniquement la difficulté s’apparente à Magento, mais si on observe que l’application n’est pas pour le moment basée sur un framework existant, on peut considérer qu’il est plus difficile d’accès.

De fait, je n’ai pas pu avoir le schéma du workflow technique de la solution comme on peut le trouver sur Magento. Ce qui fait que même après la formation, certains aspects techniques restent opaques.

Ainsi la structure MVC est par exemple masquée par une surcouche qui intègre l’action du controller dans le bloc, cet aspect simplifie le travail du concepteur de module dans les faits, mais rend également assez flou les mécanismes qui entrent en jeu.

Le workflow de Magento

Le workflow de Magento

En dehors de ça, l’application se divise en 2 grandes parties. Le « framework », qui est en fait le noyau de l’application, et les modules qui viennent enrichir le noyau. On constate que là où Magento ne distingue techniquement pas les modules noyaux des autres modules, dans RBS la séparation est nette.

Techniquement la solution n’a pas de gros défauts, pour autant elle s’avère peu accessible et se réserve donc en l’état à une frange de développeurs PHP très compétents, et donc très limitée, pour ne pas dire, oserais-je, à une élite. Or on a pu voir sur Magento, qui est pourtant plus accessible au premier abord que Change, à quel point la compétence est dure à trouver ou à former ; une personne insuffisamment compétente et c’est tout un projet qui peut être remis en cause.

Prévu en v4 : le changement majeur prévu pour la v4 de Change sera la migration du code vers Zend Framework 2, ce qui devrait éliminer pas mal de défauts d’architecture, mais surtout permettre à tous les développeurs ZF de travailler sur Change avec un temps d’adaptation réduit, et donc de s’ouvrir à plus de développeurs.

3.2 L’héritage close-source

En fait il est assez évident que Change hérite ici de son passé close-source. L’outil n’étant à l’origine mis en œuvre que par son prestataire-éditeur, le besoin d’ouverture n’existait pas, voire allait même à l’encontre d’une politique close-source consistant à verrouiller un client avec la technologie (qui n’a pas connu le fait d’être coincé avec un prestataire car il était le seul à disposer des clés de la maison…).

Il est heureux que cette politique change avec le temps, même si cela a conduit à des inconsistances dans l’architecture logicielle. Il est par exemple étonnant qu’un certain nombre de fonctions utilitaires soient disponibles dans le répertoire lib de l’application, alors qu’en parallèle des helpers sont à disposition. De même sur la traduction, gérée par le biais de fichiers XML, un par langue dans les modules, on se retrouve malheureusement avec une démultiplication du nombre de fichiers étant donné qu’il y en aura du coup un par élément (block, document, liste statique, panneau back-office, etc). Conséquence, on obtient rapidement une dizaine de fichiers dans le module, multipliés par le nombre de langues. Si ces points ne sont pas graves en soit, ils viennent néanmoins ajouter de la confusion dans une architecture qui, comme je l’ai dis, ne se laisse pas facilement appréhender.

3.3 Une configuration full XML

Une autre particularité est le fait que toutes les définitions d’éléments passent par des fichiers XML de déclaration. La création d’un nouveau document ou un nouveau block, se fera ainsi via la création d’un fichier XML, la création des classes étant automatisée. Evidemment la structure XML est complètement spécifique, et encore une fois il faudra l’apprendre. Pour autant, Change à la bonne idée de vous mettre à disposition des facilitateurs via des lignes de commande, similaire à ce qui existe dans Symfony. Par exemple, pour créer un nouveau document, on exécutera la commande « create-document » qui génèrera un fichier XML de base que vous pourrez modifier. Une fois le fichier XML terminé, il ne restera plus qu’à taper la commande « add-document » qui permettra la création de la classe et générera les entrées en base de données nécessaires. Enfin en cas de modification, les lignes de commandes créeront le patch adéquate. Si ce n’est pas forcément naturel pour le développeur, voir même carrément opaque (on ne comprend pas forcément ce que font les commandes), à l’usage c’est assez simple quand on a pris le coup de main. De plus, certaines commandes étant risquées (comme rdb : reset database), ces dernières sont alors limitées par le mode développeur, et donc non accessibles sur le site en production. Ce qui demeure important étant donné que le back-office fournit l’accès aux commandes via une interface spécifique.

RBS Change : XML

Cela nous conduit à l’un des points forts de l’application. Tout étant défini par des fichiers XML, Change possède un outil d’import XML capable d’importer absolument tout dans la solution. Les fichiers XML permettent donc de générer des sites, des documents, des blocks, et surtout du contenu. Là où cela devient intéressant, c’est que ca fonctionnera aussi sur toutes les nouvelles fonctionnalités qui seront rajoutées à postériori. Cet aspect est majeur quand on sait à quel point les imports de données peuvent être vitaux, et que Magento ou PrestaShop n’ont rien d’efficace à ce niveau, en natif. Habituellement ces points sont systématiquement développés en spécifique sur chaque projet, Change apporte donc là une véritable plus-value.

RBS Change : XML

3.4 L’accès à la base de données

Comme toute application professionnelle qui se respecte, Change implémente une DAL, dont on notera qu’elle supporte même Oracle, quand bien même a priori cela ne sera pas maintenu. Un atout indéniable par rapport à Magento puisqu’à ce niveau avec Change, il est déjà possible de travailler avec autre chose que MySql. Petit bémol néanmoins, la DAL n’est pas très intuitive à utiliser, ce qui devrait s’améliorer avec le passage sur ZF2.

Là où l’équipe de développement a fait des efforts considérables, c’est bien sur la gestion des performances. À ce jour il n’y a pas de benchmark des performances concernant Change, mais le fait est que techniquement ils ont évité pas mal de pièges, notamment sur la gestion des prix. Ceux-ci sont « compilés », autrement dit, un fichier PHP initialisant les données de prix est créé, puis simplement inclus, évitant ainsi des calculs lourds ou des requêtes en base trop longues. En fait on trouve de la compilation sur énormément d’éléments, ce qui explique d’ailleurs pourquoi nous sommes obligés en ligne de commande de recompiler après chaque modification, y compris sur les traductions. Par ailleurs, un système de cache performant est inclus, gérant nativement tous les caches habituels, incluant Redis, le petit chouchou Magento ces derniers temps. Seul défaut avoué par la team Change, la table unique, qui regroupe tous les documents, et qui a tendance à devenir obèse. Sujet sur lequel ils réfléchissent actuellement.

3.5 Concernant les modules

Concernant les modules, il est intéressant de constater qu’ils s’installent via une ligne de commande. Le serveur de Change se charge de vérifier que vous avez la licence requise avant toute installation ou mise à jour.  C’est d’autant plus intéressant que Magento ne propose rien de ce côté, et que chaque société a sa propre implémentation de vérification de licence, du moins pour les modules payants. Malheureusement il n’existe pas à ce jour de librairie de module comme Magento ou PrestaShop en possède, ce qui est bien évidemment un frein, car la popularité de ces plateformes découle en grande partie des disponibilités des modules.

Sur l’aspect modularité des développements, la solution propose 2 méthodes de surcharges : l’override et l’injection, auxquelles s’ajoute un système d’évènements et d’observateurs comme pour Magento. On regrettera l’organisation en vrac des modules, qui ne permet pas d’identifier instantanément si ils sont éditeurs, tiers ou projets. Ceci dit, l’équipe a pris en compte mes remarques, et pour la v4, l’utilisation des espaces de nom devraient faciliter un peu les choses, même si objectivement cela ne suffira probablement pas.

On ajoutera que Change intègre nativement un webservice (REST) et qu’il est extensible.

4. Stratégie et avenir

4.1 Pérennité de la solution

Dans l’immédiat la solution est viable, soutenue par les fonds de la SSII RBS, elle peut supporter les coûts de développement du produit.

À plus long terme, l’éditeur devra pour autant entamer une mutation et abandonner ses activités de mise en œuvre de la solution au profit d’une multitude d’agences, générant alors son chiffre d’affaire sur la vente de licences.

RBS se base sur la vente de modules pour gagner sa vie, le modèle a le mérite d’être simple et clair. Le prix du module est à payer une fois. Vous pouvez choisir de payer 20% du coût des modules tous les ans et de bénéficier des mises à jour, ou alors de ne pas payer la récurrence mais de repasser à la caisse le jour où vous voudrez monter en version.

Là où le bât blesse, c’est évidemment sur la disponibilité des compétences, trop technique pour le moment Change ne pourra s’imposer que dans les agences qui disposent de compétences très étoffées. Ces agences auront toujours la possibilité de vendre également, mais avec des volumes qui resteront limités en nombre compte tenu encore une fois de l’étendue des compétences à mobiliser, et surtout géographiquement contraint.

Or le modèle RBS impose comme pour Magento, une base gratuite la plus large possible. À l’heure actuelle la solution ne peut pas convaincre totalement cette base, malgré ses qualités.

Trop technique d’une part, le fait est également que si l’on ne prend que les modules gratuits que RBS propose, on dénombre moins de fonctionnalités e-Commerce que Magento, ou même PrestaShop. De plus, certaines fonctionnalités clés ne fonctionnent qu’avec SolR installé (navigation à facettes), contrairement aux concurrents chez qui ce n’est pas un pré-requis. Change a donc de gros freins qu’il conviendra de lever le plus rapidement possible ; surtout que Magento 2 arrive avec des moyens plus que conséquents.

4.2 Le positionnement de RBS

Je ne le positionnerais pas en fonction du CA de la boutique en ligne car cela n’aurait aucun sens, mais sa cible est très proche de Magento, et il est clair que Change peut s’occuper de boutique avec une très forte volumétrie.

5. En conclusion : alors, RBS Change, c’est bon ou c’est pas bon ?

Il est évident que cette solution a des atouts, sa composante CMS la distingue de ses concurrents, la partie technique est robuste, fiable et performante. On regrettera par contre que Change n’ait pas à ce jour les arguments pour convaincre des sites de moindre envergure.

Le BO n’est pas sexy, l’aspect technique trop spécifique, et certaines fonctionnalités sont payantes alors que la concurrence dispose des mêmes, mais gratuites (moteur de promotions par exemple). Autant d’éléments qui ne vont pas plaider en leur faveur pour l’adoption massive de leur plateforme.

Le fait enfin que la navigation à facette ne fonctionne qu’avec SolR, limite de façon conséquente les chances d’adoption de la solution par une communauté de petits commerçants. On oublie pour terminer trop rapidement que la place de marché de module, Magento Connect, a été l’une des clés majeure du succès de Magento, et qu’en l’absence de ce type de plateforme la lacune restera lourde à porter pour RBS.

En conclusion, la v4 est prometteuse et devrait gommer une grande partie des faiblesses préalablement évoquées, mais reste qu’elle n’est pas encore sortie. Enfin rendre gratuit certains modules est un choix politique à faire en interne, nous verrons bien si RBS arrivera à terminer son virage du close-source vers l’open-source.

Un ping pour “RBS Change : forces et faiblesses

6 commentaires pour “RBS Change : forces et faiblesses

  1. Merci pour ce retour intéressant.

    Je n’avais pas été aussi loin dans l’approche de RBS Change… mais ça ressemble à l’idée que je m’étais modélisée…

    La grande question c’est à qui va se dédier l’outil ? Et pourquoi lui plutôt qu’un autre ? Il manque peut-être un argument vraiment fort de la part de RBS… le problème c’est que tous arrivent avec le slogan “Notre solution est révolutionnaire”… ce qui en fin de compte ne veut plus dire grand chose.

    En regardant l’interface… on a vite porté un jugement aussi…

  2. Bonjour, et merci pour cet article fort intéressant !
    Mon attention avais été dans ce sens il y a un peu près 1 ans, lorsque mon client songeait a migré de son Presta vers Mag, j’étudiais des lors les alternatives Française. J’avais installé une ancienne version de FF pour jeté un œil a la démo, et m’étais dit a l’époque que cela ne plairait pas a tout le monde (car un client vient en général avec son équipe, et donc il faut imposé a tous).
    J’ai ensuite essayé de l’installer en local, résultat, ça ne s’installe pas, il fallait visiblement un NDD en bon et due forme. J’ai tenté l’instal sur un dédié pourvu d’un domaine qui sert a rien, et j’ai encore échoué sans avoir réellement d’aide via la communauté encore fragile.
    J’ai finalement abandonné, en me disant certes, que cela reste une solution a surveiller car a la difference de Prestashop, ce petit RBS, tapis dans son coin a une experience e-commerce bien supérieure. La V4 apportera surement le comble manquant.

  3. Merci pour ce remarquable article sur RBS Change.

    En effet, peu d’intégrateurs se lancent dans la solution qui nécessite un vrai bagage technique. La comparaison avec Magento sur ce point est intéressante à plus d’un titre, car trop d’intégrateurs ont cru que Magento était simple à mettre en oeuvre, avec quelques catastrophes à la clé pour les clients (j’ai des noms !).
    Donc, RBS Change n’est pas à mettre entre toutes les mains techniques, ce que l’éditeur a bien compris, en favorisant un partenariat avec des sociétés solides sur ce plan.

    Notons que le BO n’est pas rédhibitoire aujourd’hui pour les clients qui comprennent la richesse du CMS de Change, l’outil est déjà un vrai succès pour ces clients.

    Espérons que la V4 apportera de belles améliorations. L’expérience technique de RBS nous laisse penser que le produit sera costaud dès sa sortie, ce qui sera un plus pour cet éditeur français.

  4. Tout d’abord, merci pour cet article fort intéressant.
    J’aimerais apporter une correction sur la mention suivante :
    “D’une part l’accès au back-office est sécurisé via un module Firefox, son premier défaut est donc d’imposer l’utilisation de Firefox pour l’accès au BO de Change. Quand on sait que ce module ne fonctionne pas sur les dernières version du dit navigateur et voilà que votre serviteur se retrouve obligé de downgrader son Firefox pour pouvoir utiliser Change durant la formation, puis une seconde fois pour pouvoir vous rédiger cet article…”

    Cela n’est plus d’actualités depuis la version 3.6.5 qui rend compatible le backoffice XUL avec les versions récentes de firefox.
    ( http://www.rbschange.fr/blog/Produit-RBS-Change-1190/RBS-Change-3-5-10-et-3-6-5-disponibles-au-telechargement,76865.html )

    • Bonjour,

      Vous avez raison sur la correction cela provient du fait qu’à l’heure ou j’ai écrit cet article cette correction n’avait pas été faite mais ça ne change pas le fond de ce que j’ai dis : “son […] défaut est […] d’imposer l’utilisation de Firefox”.

      Il n’y plus besoin de downgrader, tant mieux car c’était lourd.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *