Quel futur pour les systèmes e-commerce

Assez rapidement, quand on développe un système e-commerce (à ma connaissance, je suis le seul à utiliser ce terme, je devrais le déposer 😉 ), on doit découper le système en plusieurs composants.

Mais le découpage est rarement satisfaisant.

Rarement satisfaisant ?

  • La plupart du temps, une bonne partie des fonctions se recoupent entre les différents composants ;
  • L’expérience des utilisateurs métier n’est pas cohérente. Chaque composant propose son propre back office, et les équipes métiers, qui travaillent sur ces interfaces, doivent jongler d’un système à l’autre
  • Les mises à jours deviennent complexes, avec des coûts et des délais difficile à bien anticiper, parce que, comme chaque composant propose sa propre logique, il faut adapter « profondément » l’évolution à chaque composant

Alors, ou est le bug ?

Est-ce une erreur de découper un problème en sous parties ?

Non, bien sûr, le problème n’est pas là.

Le problème est assez simple en fait :

Les modules qu’on assemble ne sont pas réellement fait les uns pour les autres, tout simplement.

L’assemblage est donc un « bricolage ». Je ne mets pas en doute le travaille technique (c’est un autre sujet). Mais brancher ensemble deux systèmes qui ne sont pas fait pour ça, ça ne peut pas faire une solution de qualité (malgrés les promesses commerciales…). Ou alors, le cout devient rédhibitoire.

Alors, quelle est la solution ?

Il faut être pragmatique. Cette solution n’est pas complètement satisfaisante, mais c’est bien souvent la meilleure qu’on ait sous la main. Cette réflexion est donc plus une réflexion « moyen terme » qu’autre chose.

Pour aujourd’hui, une bonne tactique, c’est bien souvent d’identifier un composant « leader », et d’effectuer un assemblage autour de ce composant central.
Un autre élément de qualité, c’est de monter une architecture SOA. Cela permet au moins de définir des contrats clean entre les composants.

Demain, je suis convaincu que les choses vont/doivent changer…

Un des éléments qui doit bouger, j’en ai la conviction, c’est la couverture fonctionnelle d’un composant.
Pour moi, c’est la base d’une architecture à base de plusieurs « briques » : chaque brique doit répondre à une description fonctionnelle très précise. Et qu’on arrête de mélanger interface et coeur du système !
Je n’invente rien en disant ça, j’applique simplement les fondamentaux de la conception modulaire, qui n’ont pratiquement pas bougés depuis 20 ans :
Un module doit définir clairement son interface métier (son API quoi) : c’est le contrat qui doit être rempli par le module.
D’ailleurs, sur des briques plus anciennes, et donc plus mûres, la promesse est bien plus claire. Exemple : un système de gestion de bases de données… gère des données. Les choses sont bien séparées entre le moteur et l’interface. On devrait avoir ce type de séparation, pour monter notre système e-commerce de demain.

C’est un sujet excitant, parce qu’il y a beaucoup à faire, et beaucoup de valeur à apporter !

Si cela vous intéresse d’en savoir plus sur ce sujet passionnant, que vous avez une expertise d’architecte, vous connaissez bien la technique, et vous vous dites que l’aventure est peut être pour vous, contactez moi !

7 commentaires

  1. Bonjour,

    Je pense que nous allons arriver rapidement à cette vision de « briques fonctionnelles ».

    Pour ma part, par exemple, je travaille avec : Prestashop + Store Commander + OpenSI.

    Prestashop me sert d’outils de vente en ligne, ses fonctionnalités sont bien plus vastes, pourtant je ne les utilise pas (facture, admin..)

    Store commander : me sert d’administration de catalogue : produits, catégories, etc.

    OpenSi : me sert d’ « ERP », gestion des commandes, CRM, Facture et comptabilité.

    Ces trois solutions sont connectées. Le problème : chacune de ces solutions essaie d’en faire le plus possible au niveau fonctionnel (pour rester, ou devenir autonome ?). Je ne pense pas que ce soit la bonne voie. La spécialité de la fonction dans la « brique » me parait être plus intéressante.

    L’idéal serait : une brique « Site de vente » + une brique « gestion du catalogue produit » + une brique « gestion Co » (commande, facture, gestion des retours, emails…) + une brique compta, le tout interconnecté.

    Chaque brique serait constituée par des spécialistes du domaine concerné, ce qui les rendrait ultras performantes dans leur domaine. Chaque brique est autonome, mais discute avec les autres. Chaque brique est administrable par des personnes spécialisées dans le domaine concerné.

    Bien sûr on met en place un SAAS en location et on devient riche c’est ça 😉

    J’aime beaucoup l’idée, y’a du potentiel, mais pour un investissement important…

  2. @François >

    Si l’on parle de briques existantes et prévues pour fonctionner entre elles, pour le marchand cela ne coûtera pas grand-chose.(enfin tout dépend qui facture…)

    En revanche, vu que ce système de « briques fonctionnelles » prévues pour une solution « globale » et « scalable » n’existe pas, pour l’éditeur cela représente un investissement de développement important.

    Ce qui est vraiment intéressant dans cette approche, et qu’elle n’a pas de limites en terme de fonctionnalités. Si l’on trouve un format de dialogue entre des briques indépendantes tout devient possible : Ajout d’une brique SEO (type SEO moz), Ajout d’une brique site relation presse, etc.

    ça y’est j’ai envie de monter un nouveau business 😉

  3. Salut François,

    c’est un sujet sur lequel on a débattu plusieurs fois ensemble . Pourtant, je dois bien admettre que mon point de vue a évolué récemment.

    Je pense sincèrement qu’il n’y a pas 1 solution. (n’y aura jamais ? je suis pas loin de le penser)

    Cela dépend vraiment des contextes métier , de la maturité des environnements techniques et client. (« la culture » de l’entreprise : il est très important ce point!!)

    Il faut essayer de tirer partie des forces et faiblesses en présence

    Certes, du point de vue de « l’état de l’art » , c’est rarement satisfaisant.

    Mais sincèrement , le plus important n’est-il pas que le e-commerçant améliore son business ? Je crois que si !

  4. @Majureo> Bien sur que si !

    Je fais des articles courts, et donc forcément réducteurs.

    Je n’ai donc pas détaillé les problèmes métiers (j’ai juste parlé de la complexité des back offices, ce n’est bien sûr qu’un petit aspect des choses).

    La technique n’est qu’un outil, on est bien d’accord !

Laisser un commentaire

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