Archives par mot-clé : Système d’information e-commerce

Le modèle de données, au coeur du métier du e-commerce

C’est marrant la vie.

J’ai commencé par me passionner pour la modélisation des données, et les systèmes pour gérer ces données, les systèmes de gestion de bases de données (SGBD pour les intimes).

j’avais travaillé, pendant mes études, sur un système innovant, orienté objet.

La réflexion, dans le courant de ce que faisait O2 à l’époque, était de travailler sur un système de modélisation, permettant de faire « plus et mieux » que ce que propose les SGBD relationnels.

J’avais même acheté un NeXT pour développer une première version du système ! A l’époque, c’était un investissement très élevé, le prix d’une belle voiture neuve…

A la base, la réflexion, c’est de ce dire que la modélisation c’est super important, parce que c’est la « racine », et qu’ensuite, on empile les couches par dessus cette brique.

C’était bien avant le Web, bien avant le e-commerce.

Et aujourd’hui, je me rends compte à quel point ces réflexions restent d’actualités.

Dans les systèmes web, les bases de données sont, plus que jamais, au coeur du système.

Plusieurs experts du domaine, que je connais, commencent leurs analyses à partir de l’audit du système de gestion des données, relationnel dans 99% des cas.

Si une donnée est mal modélisée dans la base de données, il y a peu de chance pour que les choses s’améliorent sur les couches supérieures.

Le modèle relationnel est il fondamentalement pourri ?

Non, bien sûr que non !

Comme souvent en informatique, le pouvoir d’expression n’est pas en cause : on peut tout modéliser avec une base de données relationnelle.

C’est bien pour ça d’ailleurs que ce modèle a survécu, et même écrasé les modèles alternatifs des années 80 / 90.

La théorie, c’est qu’on n’a qu’à rajouter les couches qui vont bien, par dessus le modèle relationnel.

Ainsi, on peut très bien ajouter une couche objet, entre la programmation et le base de données.

Cela marche bien… Sauf que le Web challenge tout ça.

Les serveurs web se servent de la base de données pour beaucoup de choses, en permanence, en temps réel.

Résultat, la base de données devient rapidement « le maillon faible » du web, vis à vis des performances. On doit optimiser la base pour qu’elle réponde vite, et donc avoir de bons temps de réponses sur le site web.

Conséquence : on oublie la qualité de la modélisation, les formes normales pour ceux qui connaissent, et on fait de bons grosses tables plates, capable d’afficher rapidement les informations dont on a besoin.

Bon, l’autre problème, c’est que les bons concepteurs de bases de données ne courent pas les rues…

Je suis convaincu que les choses doivent évoluer… Vont évoluer !

On doit, par exemple, ajouter des couches, de manière à séparer le coeur du modèle de données – ou l’on doit privilégier la qualité de la modélisation – et la couche de présentation, on l’on doit privilégier les temps de réponses.

Bref, la modélisation de données, c’est un bon fil rouge, entre hier, aujourd’hui et demain !

Tout ça pour dire que, entre le début de ma vie professionnelle et aujourd’hui, je me rends compte à quel point tout cela est cohérent.

Formation : Choix des composants e-commerce

Je donne, principalement avec le CCM Benchmark, des formations.

Le sujet de la prochaine session est : « choix des composants pour le système e-commerce« .

De mon point de vue, c’est un super sujet ;).

Quels sont les composants clés à choisir ?

Comment construire son système e-commerce, entre le searchandising, le CRM, la logistique, … ? Sur quels critères ?

Au delà des briques, comment conduire le projet e-commerce ? Les technos, les boites, il s’agit de ne pas se tromper !

Ces questions sont très impactantes pour la suite, pour la vie du site.

Pendant cette journée, après un « overview » de quelques sujets clés, on prend le temps de se poser les bonnes questions, de prendre du recul, et d’échanger sur ces problématiques clés.

Pour tout savoir, c’est ici. La formation a lieu le 12 janvier, à Paris.

Généraliser ? Oui, mais pas trop !

Une bonne partie de mon activité consiste à concevoir, ou aider à concevoir, un système d’information e-commerce.

Pour faire ça, il faut une bonne culture sur ce qu’est un système d’information (ce qui va bien au delà du site Web), connaître les solutions du marché (en tout cas, faire une veille permanente pour en savoir le plus possible), et enfin, et surtout, écouter le client, pour comprendre en détail le besoin.

De mon expérience, qui commence à être bien solide, ce travail demande de comprendre, d’analyser, et de retranscrire ce besoin, dans un doc.

Mais il ne s’agit pas de retranscrire tel quel (sinon, la valeur ajoutée est nulle).

Première chose, quand on conduit l’interview, on doit creuser certains points, valider certaines hypothèses.

On peut aussi, en fonction de la capacité d’écoute de l’interlocuteur, essayer d’infléchir, ou tout au moins « challenger » certains éléments, que l’on sait particulièrement complexes, ou non pertinent.

Enfin, et c’est le sujet de cet article, on doit extrapoler, généraliser la demande du client.

A ce sujet, j’avais rencontré le CTO de Radio France, il y a quelques années.

Il m’avait raconté comment cette faculté de généralisation lui avait juste sauvé la vie : on lui avait demandé la mise en place d’un nouveau système avec des contraintes précises sur les horaires. Il avait pris l’initiative de généraliser la demande, pour traiter plus de cas de figures, sans rien demander à personne. La veille de la mise en exploitation du nouveau système, on lui annonce un changement, qui justement était parfaitement pris en charge par son système !

Bon, mais dans notre monde du e-commerce, cela veut dire quoi généraliser ?

Je vous propose de prendre quelques exemples :

On vous demande de pouvoir créer deux espaces de vente, orienté marketing (genre Nouveautés et Soldes). La généralisation va consister à dire qu’on peut gérer N espaces de ventes.
On vous demande qu’un produit puisse être simultanément dans deux catégories du catalogue. Généralisation : un produit peut être dans un nombre quelconque de catégories.
On vous demande une barre de menus, avec des couleurs associées à chaque menu. Généralisation : on peut ajouter facilement des menus, et changer la couleur avec un seul paramètre.
On vous présente une page d’accueil, découpée avec des blocs. Généralisation : définir une grille, administrable, qui permettra facilement de faire évoluer la home page (exemple réel, en ligne…)
Je pourrais multiplier les exemples, sur tous les sujets : CRM, logistique, transporteurs, …

Avantage de l’approche : généraliser permet (doit permettre…) de construire un système plus évolutif, apportant plus de pérennité.

Mais cette approche est a des limites. On ne doit pas généraliser n’importe quoi.

Certains éléments, généralisés à mauvais escient, vont pousser dans la mauvaise direction, soit en contraignant à prendre des solutions bien plus chères, ou vont induire des choix d’architecture qui ne seront pas en phase avec les réels besoins de l’entreprise. Au bout du compte, cela peut coûter bien plus cher sans apporter aucun gain.

Alors, on fait quoi ?

Je n’ai pas de réponse « industrielle » à cette question !

Je pense que c’est la « clé du succès », ce réglage fin, entre ce qui doit être généralisé, et ce qui ne doit pas l’être.

Ce réglage se fait par analyse, synthèse, prenant en compte de très nombreux facteurs : ce que font les solutions du marché, une intuition des réels besoins de l’entreprise, une évaluation sur le coût réel de la mise en oeuvre de la généralisation, …

J’insiste : certaines généralisations se retournent et deviennent des handicapes. Je vais pas balancer, mais je connais des solutions, qui ont été construites avec une volonté évidente de « généricité » et qui sont en fait très complexes à faire évoluer.

Donc, en synthèse : oui, il est fondamental de « prendre de la hauteur » , et de chercher à généraliser, pour construire un système qui sera opérationnel plus longtemps. Il faut juste faire ça avec doigté ;).

Comment construire son système d’information e-commerce ?

Quand on conçoit un système d’information, en général, ou pour le e-commerce, on définit des modules, et des liens entre les modules.

Quand je travaille sur ces sujets, je dis souvent que ces liens peuvent représenter un enjeux au moins aussi important que les modules eux même.
Quelques exemples de connexion de modules :

Brancher la brique e-commerce avec un module CRM
Brancher la brique e-commerce avec un ERP
Brancher la brique e-commerce avec le logiciel de comptabilité
Dans le cas d’un front office séparé du back office, synchroniser le front office et le back office
…

Donc, comment connecter les modules ?
En fait, la plupart des modules sont structurés à partir d’un système de gestion de bases de données.

Il peut être tentant de réaliser le branchement directement de base de données à base de données.

C’est d’autant plus tentant qu’il existe des solutions pour synchroniser les bases de données (solutions type ETL).

L’avantage de cette solution est qu’elle est relativement rapide à mettre en oeuvre, et qu’elle n’est pas « prise de tête » : on se branche, on va chercher l’info et zou, c’est bon.

L’autre solution, c’est de développer une vrai couche de connexion, basé sur des web services.

Evidemment, développer une telle couche métier à un coût. Quel est donc l’intérêt alors de faire comme ça ?

Les avantages sont multiples :
Cela permet de définir une vrai couche abstraite, orientée métier. Cette couche doit être indépendante des deux modules en fait. Elle permet donc d’ajouter de la flexibilité, de l’évolutivité dans le système.
On peut en particulier ajouter des traitements sur les données, et « servir » des données bien plus synthétiques que ce que propose les bases de données natives.

Remarque : une couche métier peut très bien communiquer vers plusieurs modules pour générer une donnée de synthèse (exemple : aller chercher, pour une info client, des éléments sur la brique e-commerce et dans un système CRM).

Mettre en place une telle architecture demande donc un vrai investissement, fonctionnel et technique.

Mais c’est à mon sens la seule solution pour avoir un système d’information réellement évolutif.

Si on y réfléchi bien, ne pas faire ce travail de couche métier, cela revient à lier fortement les deux modules, à diffuser des éléments d’implémentation, d’un module vers l’autre.
Avec le temps, les deux modules vont être de plus en plus imbriqués les uns dans les autres, et toute évolution deviendra vite un cauchemard : comment faire une monté de version d’un module, surtout si la nouvelle version impacte la base de données ? …

En fait, si on y réfléchi, c’est la seule solution pour faire une archi un minimum évolutive et stable.

Barcamp Prestashop le 24 Novembre

Le quatrième barcamp Prestashop aura lieu le 24 Novembre.

8 conférences, 8 ateliers, toute la communauté Prestashop sera là.

C’est une bonne occasion pour glaner de bonnes infos, rencontrer d’autres e-commerçants ou prestataires, …

L’évènement a lieu, comme la dernière fois, à l’Espace Tapis Rouge, 67, rue du Faubourg Saint-Martin – 75010 Paris

Pour s’inscrire, c’est par ici.

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 !

Interface or not interface

Discussion passionnante, hier, avec Theodo.

On a pas mal échangé, en particulier sur les interfaces.

Bien sûr, côté Front Office, la question ne se pose pas : on se doit de proposer des interfaces faciles à utiliser, intuitives, rapides, …

Mais la question peut se poser côté back office.

Autant il est évident que certaines fonctions se font très bien via des interfaces, bien souvent web. Exemple : ajouter ou mettre à jour un produit dans le catalogue, ajouter une image, …

Mais pour certaines fonctions bien plus avancées, la question peut se poser.

Exemple : gestion des processus (workflow).

Est-ce vraiment une bonne idée que de développer un moteur graphique, pour représenter des choses aussi complexe que la modélisation des processus ?

Regardons les deux faces du sujet :

Si on a une interface :

L’interface donne un cadre, et elle permet de contrôler qu’on reste dans ce cadre.

Si on prend l’hypothèse que cette interface est bien faite, (hum hum), cela va permettre d’aider l’utilisateur à paramétrer le système.

Exemple intéressant de mon point de vue : le module de paramétrage des promos sur Magento.

Bon, l’exemple est certe particulier, parce qu’on voit bien que le résultat est finalement très très proche d’un programme…

Si on n’a pas d’interface :

Si on n’a pas d’interface, on va devoir utiliser un langage de description du sujet.

Ce langage peut être un langage hôte (PHP, Java, …) ou une syntaxe XML ou YAML, ou enfinun nouveau langage spécifique.

Si on prend un langage hôte, l’avantage est qu’on peut exprimer directement le problème sous forme d’un programme.

L’énorme avantage est qu’on n’aura pas à développer d’interface, complexe et très cher.

L’inconvénient est qu’on a probablement perdu 99% des utilisateurs métiers du back office. Pour modifier un élément, il faudra faire appel aux développeurs.

Alors, en synthèse ?

C’est un vrai sujet, il faut voir au cas par cas.

en fait, il y a toujours une limite, entre ce qu’on peut faire avec le back office, et ce qui doit être programmé. Certains systèmes essaient de repousser très loin la bascule vers la programmation, mais cette bascule existe toujours, et c’est pas prêt d’être fini : je ne crois absolument pas en « la fin de la programmation » avec la « programmation graphique » type UML… C’est un leurre marketing !

Quelques idées en vrac :

Si il s’agit d’une opération répétée régulièrement par les utilisateurs du back office, pas d’hésitation, il faudra une interface, et plus l’opération sera répétitive, et plus l’interface devra être soignée, pour faire gagner du temps aux équipes ;
Si l’interface s’avère très complexe, il arrive que la question prenne du sens : développer l’interface peut être très coûteux, et finalement pas rentable du tout, parce qu’en réalité, les utilisateurs n’utiliseront pas cette interface. Exemple : qui utilise un modeleur de processus d’un ETL ? Des informaticiens, qui iraient bien plus vite en programmant…
Si on doit « modeler » un problème via un langage de programmation, il est fondamental de développer des couches qui permettent d’exprimer le problème avec un bon niveau d’abstraction. C’est très important, parce que sinon, la mise à jour du programme sera compliqué, cher, … On ne fait pas toujours ce travaille, et c’est un vrai problème !

Bien choisir sa plate forme e-commerce

C’est une question qu’on me pose régulièrement, via le blog, par mail, lors de conférences ou dans le cadre de missions de conseils.

Bien souvent, mon interlocuteur, posant une question simple, attend une réponse tout aussi simple.

Malheureusement, il n’y a pas de réponse simple à cette question.

Et méfiez vous de ceux qui disent le contraire…

Alors, pourquoi ne pas faire un classement, de la moins bonne plateforme à la meilleure ?

Pour plusieurs raisons :

Il y a de nombreux critères à prendre en compte, quand on choisi une solution, et ces critères sont différents, d’un projet à l’autre.

Comment mettre dans un même panier des solutions pour des sites adaptés à des TPE et des solutions pour les grands groupes, orienté multi canal ?

Quand on se lance dans le e-commerce, si on le peut, le mieux est de partir sur des solutions SAAS, permettant de démarrer pratiquement sans investissement. Citons Oxatis, Powerboutique, Wizishop, Rentashop.

Ces solutions permettent de mettre en ligne des boutiques très correctes, et de concentrer son budget sur d’autres éléments tout à fait fondamentaux : le stock, l’acquisition de trafic.

Pour choisir, entre ces solutions, je vous suggère de passer beaucoup de temps sur les différentes boutiques en lignes réalisées avec ces solutions. Analysez les parcours clients, l’ergonomie, les temps de réponses. Contactez les e-marchands, qui bien souvent seront tout à fait prêt à vous parler de leur expérience.

Mais après, quand on est sur des projets plus complexes, plus riches, ou ces solutions ne sont plus adaptés, les choses deviennent bien plus compliquées.

Ce que je peux dire, c’est qu’il ne faut absolument pas se limiter à une analyse fonctionnelle. C’est tout à fait insuffisant, voir inutile.

Pourtant, les éditeurs mettent en avant des listes à rallonge de fonctionnalités….

Pourquoi l’analyse fonctionnelle est elle limitée ? Prenons un exemple : vous avez besoin de mettre en place des mécanismes de promotions. Vous allez donc chercher, dans la liste des fonctions, s’il y a une ligne du type « promotion ». Mais quelles types de promotions voulez vous faire, et ces promotions sont elles possibles sur telle plate forme e-commerce ? Vous voyez ? La simple liste fonctionnelle est bien insuffisante.

Vous voyez ce que je veux dire ? Pour vraiment creuser au niveau fonctionnel, il faut rentrer dans le détail, à un niveau vraiment très fin, pour savoir si une solution est vraiment adapté à votre besoin.

D’autres critères sont au moins aussi importants.

Ce que fait la solution « out of the box » comme on dit, c’est une chose. Mais vivre plusieurs années avec la solution, c’est autre chose. Il est donc très important d’avoir une solution qui sera vraiment évolutive. Cela veut dire que vous pourrez faire évolution votre site, votre plate forme e-commerce, rapidement et avec des coûts raisonnables.

Pour ça, il faut plusieurs choses :

Il faut que la solution soit bien écrite à la base, que la structure soit évolutive ;
Il faut également que des équipes techniques maîtrisent bien ce code. Il est donc tout à fait important de voir quels sont les prestataires qui pourront travailler sur la solution ;
La solution peut évoluer via un éco système, une communauté. C’est bien sûr le cas pour les solutions open-sources, comme Magento, RBS Change, Prestashop, Oxid eSales… Dans ce cas, il est important de mesurer la taille et la dynamique de la communauté

Plus largement, ce qu’il faut prendre en compte également, c’est :

Le prix de la solution, et le prix des développements à faire pour avoir votre boutique ;
La technologie employée (Java, PHP, C#…) et sa compatibilité avec les autres solutions que vous utilisez
Le mode de solution : SAAS ou pas. Il existe des solutions SAAS pour les très rands projets, je pense bien sûr à Demandware.
Le dynamisme de l’éditeur et de la communauté : a quel rythme sortent les nouvelles versions ? Et quelles sont les nouveautés proposées
Les références, bien sûr, qui reste un facteur important, quelque soit la taille de la boutique

Bon, vous le savez, je fais des billets courts, je ne vais donc pas faire le tour de cette question ici, cela mériterait un livre…

Payzen, plateforme de paiement innovante

Pour un site e-commerce, la solution de paiement est importante, tant pour les clients que pour le back office.

Pour les clients, il s’agit de leur proposer une interface fiable, rassurante, efficace, rapide.

Pour le back office, il y a aussi des enjeux : la qualité de l’interface du back office permet aux équipes de mieux travailler et de gagner du temps.

Les deux faces de ce sujet sont clés !

Côté Front Office, on peut comparer très facilement ce que proposent les différentes solutions.

Je pense que l’avenir est plutôt au paiement déporté sur le site de la banque, mais pour que cela soit réellement performant, il faudra encore améliorer certains points, et permettre de :

Mieux personnaliser le traitement des erreurs sur la page de paiement (aspect souvent délaissé, à tord) ;
Permettre d’ajouter des éléments dynamiques sur la page, pour afficher, par exemple, le contenu du panier.

Côté back office, j’ai passé un peu de temps avec Payzen.

Paysen est l’un des PSP (Payement Service Provider) du marché.

La solution a de belles références, comme Alinea, Edel…

En fait, derrière Payzen, il y a Lyra Network.

Lyra network, c’est 2 milliard € de transactions en 2009 !

La solution respecte toutes les normes de sécurité du marché comme PCI-DSS (norme de sécurité américaine pour le paiement en ligne).

Côté back office, PayZen propose un back office très pro, très propre, et plutôt riche.

L’interface a clairement été réfléchie pour être facile à utiliser, et propose tout un tas d’options permettant de gagner du temps.

Exemples :

On peut effectuer une recherche, sur tous les paiements effectués depuis une carte, par un simple drag & drop
On peut personnaliser facilement et rapidement la liste des transactions : changer l’ordre de tri, changer l’ordre des colonnes, ajouter une colonne….
…

Autre point qui m’a semblé intéressant : la solution permet de programmer la personnalisation des pages front office de paiement, directement depuis le back office.

Côté fonctionnel, la solution permet de gérer les paiements récurrents (abonnements, …), intègre un mécanisme de détection des fraudes (avec un mécanisme de scoring à venir prochainement).

D’un point de vue technique, la solution a développé des connecteurs vers les principales solutions e-commerce du marché : Prestashop, Magento, OS Commerce.

La solution peut également être intégrée sur le site.

Si le paiement n’est pas intégré, il se déroule en trois étapes :

Choix du type de paiement (cette page peut intégrer le Paypal)
Paiement
Confirmation de paiement, avec affichage du numéro de transaction.

Breaking news : Oracle achète Endeca

A peu près un an après avoir acheté ATG, Oracle vient d’annoncer l’acquisition de Endeca, solution de searchandising.

Le searchandising, pour ceux qui découvrent ce blog ( 😉 ), c’est une solution logicielle, qui enrichie le système e-commerce, et qui vise à « proposer le bon produit, au bon moment, au bon client ».

C’est donc un composant logiciel, qui se branche sur le front, et qui permet de :

Gérer les catégories, avec des notions de filtres avancées
Gérer un moteur de recherche, avec des résultats même si la recherche est imprécise (correction de fautes de frappe ou d’orthographe)
Trier intelligemment les produits, pour présenter en tête de liste les produits qui se vendent plus
Proposer automatiquement des liens entre les produits (cross selling automatique intelligent)
…

Oracle devrait proposer une intégration packagée entre les produits ATG et Endeca.

Cela ciblera probablement les très gros projets (ce qui est déjà le cas de ATG).

Les autres acteurs du domaine sont :

FredHopper, racheté par SDL, mais qui reste une entité autonome sur son métier
Compario, solution française
Et d’autres solutions, comme Autonomy, Celebros, FactFinder

A suivre, il y aura sans doute d’autres annonces sur ce secteur stratégique.

L’annonce ici.

(merci Adrien pour l’info)