Système e-commerce : intégration, par le haut ou par le bas ?

Un système e-commerce, c’est l’ensemble des composants, qui font fonctionner le site e-commerce.

Bien sûr, cela comprend un (ou plusieurs) Front office, mais également un ou plusieurs back offices, un CRM, le branchement vers les autres systèmes d’information de l’entreprise, …

Au système d’information e-commerce pour un site un peu important, c’est rapidement près de 10 composants, qui doivent travailler les uns avec les autres.

Au fil de la vie du site, on doit ajouter de nouvelles briques.

Par exemple, on souhaite enrichir le site avec un système d’avis utilisateurs (type BazaarVoice ou PowerReview), ou encore avec un moteur qui va gérer des publicités à l’intérieur du site (un ad-server interne au site).

Comment réaliser cette intégration ?

Il y a deux approches, presque opposées : l’approche par le haut ou l’approche par le bas.

Par le haut

Le principe est de ne pas vraiment s’intégrer en fait : on effectue juste quelques modifications du code Front, avec l’ajout de tags et de Javascript.

Ensuite, les deux systèmes vont tourner en parallèle. Le nouveau module pourra tout faire à partir des légères modifications réalisées sur l’interface.

C’est typiquement comme ça que s’intègre d’ailleurs les outils d’avis utilisateurs. C’est également comme cela qu’on intègre la fonction de Web Analytics.

Par le bas

Il s’agit d’une vrai intégration. Le nouveau composant est branché sur le système e-commerce, et les informations qui doivent remonter sur le Front passent par l’architecture standard du site.

Avantages et inconvénients de chaque solution

L’intégration par le haut à plusieurs avantages :

  • L’intégration est très rapide, puisqu’en fait, on ne modifie presque rien.
  • Le coût d’intégration est donc mécaniquement réduit.

Beaucoup de briques e-commerce se développent en proposant ce type d’intégration.

La maintenance du système d’information est toujours un sujet sensible : cela coute cher, les équipes techniques ne vont pas aussi vite que ce que voudraient les équipes métiers…

Les éditeurs de logiciels l’ont bien compris, l’approche par le haut leur permet de « rentrer » plus facilement, avec une promesse simple  : mettez en oeuvre notre solution en quelques clics, sans avoir besoin d’une intégration longue et chère.

Alors, pourquoi s’embêter ? Pourquoi ne pas tout intégrer par le haut ?

En fait, cette intégration miracle peut cacher plusieurs désavantages : back office non intégré, trop de javascript sur la page, SEO difficile à travailler…

Comme toujours, il n’y a pas de recette miracle, pas de solution magique.

L’intégration par le haut peut être une très bonne chose dans certains cas, mais c’est une approche à « consommer avec modération ».

 

 

11 commentaires

  1. L’approche par le haut à un seul avantage: rapide et pas cher. C’est donc parfait pour valider un concept, tester une idée, ou mettre en place un truc périphérique, c’est à dire une fonctionnalité qui n’est pas au cœur de son système. Dès qu’on devient sérieux sur un projet de ce type, il faut réintégrer: approche par le bas. Parceque sinon c’est une recette pour la catastrophe. L’intégration par le haut à tout du bricolage.

  2. 100% en ligne avec Pieroxy, ce que tu décris comme « intégration par le haut » est typique de ce que tous les « marchands de miracles » proposent, après,
    1 – Tu pers le controle de ton site c’est le prestataire externe ou le tier qui maîtrise le contenu de ton site ….
    2 – Tu dois gérer un tas de back office qui, évidemment ont des fonctionnalités proches … et la l’enfer commence
    3 – Comme dans les conflits armés – il y a toujours quelqu’un de plus fort qui proposera quelque chose de mieux, de plus de meilleur … et c’est frustration et consort en permanence
    4 – ton coeur applicatif, évolue, et lors d’une mise à jour (montée de version) il y a une probabilité non négligeable que des fonctionnalités qui ont été externes – soient dedans – et la encore porte ouverte sur l’enfer pour « détricoter »

    Pour une validation de concept, pour une mise en ligne rapide en réponse à une demande du marché, pour montrer de la réactivité, j’ai l’habitude de recommander d’avoir dans son coeur system une « plage de jeu » qui permette aux « Business » de tester, d’essayer, de s’amuser, etc. avec des nouveaux concepts mais toujours dans ‘larchitecture de l’application maître et toujours avec une régle simple : C’est par construction et par définition EPHEMERE !

    Ce faisant, pas de frustration coté business qui peut développer des tas de concepts, pas de frustration coté IT/Technique qui sait qu’une partie de l’architecture est dédiée à cela et qu’elle est en charge de « réintégrer » proprement ce qui aura fait ses preuves.

    Et puis Vive le SOA et l’appel de services via un ESB/EAI … mais c’est un autre sujet notamment lorsque l’on parle de logiciel de eCommerce comme ATG ou WebSphere Commerce …

  3. @Pieroxy, Jean Michel> Merci pour vos commentaires !!!

    En fait, j’avais commencé ce billet en listant tout les problèmes de l’intégration par le haut, puis j’ai simplifié, en me disant qu’il serait beaucoup plus intéressant de faire ça via les commentaires 😉

    Sur le fond :
    Sur certains sujets, comme l’analytics, l’intégration par le haut est devenue un standard….
    Et puis je pense qu’au fond, c’est aussi une question stratégique : veut on construire un système e-commerce comme un actif pour l’entreprise ?
    Si oui, intégration par le bas.
    Sinon, ou si on n’a pas le temps, pas les moyens, … l’intégration par le haut permet d’aller vite… Même si, je suis bien sûr d’accord, c’est pas très satisfaisant d’un point de vue archi

  4. La gestion des nombreux back office est franchement galère… typiquement pour l’acquisition de trafic avec 15 ou 20 sources : affiliation, seo, pub, adwords,comparateur1 ,comparateur2 etc…
    Mais le coût d’intégration doit être très elevé et la faisabilité n’est pas toujours assuré…

  5. Pour des intégrations de type Coremetrics ou Omniture, je ne parlerais pas d’intégration par le haut, même si je comprends ton point de vue. Pour ces « tools » rien de visible pour l’utilisateur, les tags et autres scripts sont à mettre dans les JSP – pardon les pages ou tu souhaites tracker l’activité, difficile d’imaginer autre chose.

    Pour les avis d’utilisateurs (shopzilla ou Bazarvoice ou autre), pour l’intégration de contenus « localisés » (type ViaFrance ou autres), ou pour des intégrations de « catalogues » numériques (du Flash XML) soit tu as de la chance et tu peux disposer de webServices et tu gardes le controle, soit … tu passes par excel et photoshop pour envoyer tes contenus par mail ou pire par snail post sur un CD, puis les récupérer sous forme de flash ou autres formats hétéroclites et il faut les mettre au chaussse-pied dans tes pages …

    Je parle même pas des « micro sites » en pure JS ou en Flash ou le prestataire taquin place des tags « humoristiques » dans les images (si si je l’ai vécu) …

  6. @Benoit> Oui, c’est un des critères… Ceci dit, rien n’empêche une intégration par le haut, et la fusion des back office, avec un accès web services aux fonctions d’administration.

    Bref, intégration par le haut pour le front et intégration via des web services pour le back office… pour autant que la solution le permette (Google Analytics le permet par exemple)

  7. @Jean Michel> Oui, ta segmentation est intéressante : il y a les briques qui affichent quelque chose et celle qui n’affichent rien, c’est sûr que c’est pas la même chose.

  8. François,

    Tu dis « c’est pas très satisfaisant d’un point de vue archi » Un peu comme on dirait que c’est pas joli, pas esthétique.

    C’est un problème technique qui a des implications profondes. En premier lieu, dans un navigateur, on n’est pas aussi maître de son environnement que sur le serveur. Du coup, intégrer « un tag » n’a pas les mêmes implications qu’intégrer une librairie ou un webservice côté serveur: Le tag va évoluer a gré de son hôte et il interagit directement avec votre appli. C’est lui qui devient maître de ce qui se passe quand il est exécuté. C’est une lourde responsabilité !

    Plus il y en a, plus il y a de chances qu’un d’entre eux ne la joue pas bien avec un autre. Et là c’est la cata: erreurs en tout genre sur le client, le plus souvent indétectables car limitées à un contexte technique précis (un navigateur précis, un type de latence réseau donné comme du Edge ou de la 3G, etc.) Évidemment, dans la majorité des cas, personne ne voit rien. Sur le site où je travaille (tu le connais) on a eu un « bug » de ce type qui affectait IE6 et 7 sur XP SP1 uniquement. 50% des fiches produits ne s’affichaient plus. Je m’en suis aperçu et je me suis également aperçu que ça faisait 3 mois qu’on était dans cette situation. 4% de l’audience… pouf ! Ca va vite, très vite.

    Mais le plus grave dans tout cela c’est la sécurité. C’est le plus grave et le moins traité des problèmes. Un tag sur la page de login? Hop, le partenaire peut récupérer le mot de passe sans problème. Un tag sur la page de paiement? Hop, le partenaire peut récupérer toutes les coordonnées saisies par le client. N’oublions pas qu’un tag est « dynamique ». Il peut choper tout ce que fait l’internaute. Alors avec les 10 tags d’une fiche produit « classique » plus un formulaire de login dans le header, les vecteurs sont presques illimités.

    Tu me diras, c’est une question de confiance dans le partenariat. C’est sûr. Mais le hacker il s’en fout lui de ton partenariat, il viendra chez toi tout pareil une fois qu’il aura hacké ton partenaire.

    J’imagine le jour où Xiti ou Eulerian se fera hacker. En 5 minutes ils peuvent sans doute récupérer 10.000 carte bleues, avec date d’expiration et CVV. Avec la quasi-certitude que PERSONNE ne s’en apercevra jamais s’ils ne sont pas trop gourmands et se cachent avant d’être découvert. Très sérieusement, je ne serai pas surpris de savoir que c’est déjà arrivé – dans l’ignorance de tous.

    Bon, j’arrête de te faire suer ! Salut.

  9. @Pieroxy> Merci pour cet avis éclairé !

    Tu as raison, l’approche par le haut présente pleins de défaut, qui peuvent s’avérer dramatiques.

    Le problème, c’est que les risques dont tu parles, les décideurs ne les perçoivent pas.
    Tu te retrouves donc à secouer un chiffon rouge, tu vois le danger, mais les autres, non.

    Et en plus, comme tu le dis, les problèmes de sécurité, de fraude ne sont pas forcément rendus publiques. Cela agrave la non visibilité sur ce type de problème. On peut te répondre « ce que tu es pessimiste, regarde, tout va très bien ».

  10. 200% en ligne avec Pieroxy, la sécurité c’est évidemment le pb des intégrations « à l’arrache » (cf mon allusion aux tags humoristiques).

    Et comme toujours la sécurité, c’est quand il y a un pépin que les décideurs:
    1- cherchent un lampiste pour assumer des décisions qu’ils n’ont pas pris
    2- Crient au scandale

    Too late ! mais surtout douloureux pour tous le monde, l’image de l’enseigne, les clients abusés, le prestataire … bref un chapitre à ajouter à l’Ouvrage « Réaliser votre site eCommerce, Les 10 choses à faire pour que aller à la Catastrophe »

  11. Tres bon post, je ne connaissais pas les appellations « par le haut » et « par le bas » mais je trouve que ça résume bien la situation.

    Entre les deux niveaux, il y aussi les modules pour Prestashop et Lengow qui permettent de tester des solutions sans trop de risque.

    Pour ma part, je défend l’approche par le haut qui peut aussi débloquer des solutions ou les équipes marketing sont en situation de frustration et de blocage par rapport à des contraintes techniques. Par contre, c’est vrai que l’accumulation de tags sur un site peut générer des incompatibilités et des lourdeurs de chargement (en plus des bugs et failles de sécurité). Mais il y aussi des solutions qui se mettent en place pour centraliser la gestion des tags.

    Au final, je pense que les solutions avec intégration par le haut répondent exactement à la demande actuelle des E-Commerçants: Obtenir un retour sur investissement rapide et gagner en agilité marketing. ça ne relève pas du miracle, c’est juste un rapport rationnel entre le risque lié au développement (qui peut prendre beaucoup de temps et coûter très cher pour pas grand chose) et le retour sur investissement escompté. Sur ce point là, les solutions avec intégration par le haut me semble présenter un avantage indéniable.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.