La synchronisation est un problème difficile, et bien qu’il semble facile pour celui qui a inventé le terme, il est en fait un défi permanent pour les développeurs, quand on prend en considération la performance et la cohérence.

Cohérence

La cohérence est le fait que le système de contrôle et le site e-commerce sont toujours au même niveau d’information. Ce qui est dans le CRM est dans le site Web, et ce qui est dans le site Web est également dans le CRM.

Ou pas. Parfois, volontairement, la synchronisation est unidirectionnelle: l’information descend de l’un des serveurs, et est utilisée par le second. Le second système doit utiliser l’information qui est déjà prête : le second système ne peut pas faire de modification, comme le premier, aussi appelé le maître. Ceci est caractéristique de deux types de situations: quand le site web e-commerce est une évolution ou un complément d’un système plus vaste en interne. Cela arrive souvent lorsque les détaillants se tournent vers le Web. Ils ont déjà un système existant, tel un ERP ou une gestion de stock. Ainsi, le e-commerce prend les informations du système d’origine, et les publie sur le web. L’autre situation est lorsque le système interne est considéré comme stratégique, et que la compagnie ne veut pas l’ouvrir, pour des raisons de performances, de sécurité ou encore d’organisation. Afin de découpler les deux, la synchronisation est donc mise en place.

Cette synchronisation est l’approche la plus simple, et une fois qu’elle est bien assimilée, la « synchronisation bidirectionnelle » débarque. Évidemment, il y aura tôt ou tard, les informations du site web qui devront être mis à la disposition du système original : le CRM a besoin de voir les informations mises à jour des profils (contact), tout comme le site Web a besoin d’avoir les informations de contact mises à jour. Ou encore, le site web produit de nouvelles données, comme le nombre de vues pour chaque article, que les ERP souhaiteront utiliser afin de planifier le processus d’achat suivant.

Ces deux types de synchronisations sont les deux principales. Des solutions hybrides existent, et comprennent: une synchronisation à double voie (chaque serveur est maître pour un ensemble distinct de données), la synchronisation avec modération (l’un des serveurs sera le maître, et recueillera des données pour la résolution des conflits, avant de le pousser vers le second serveur), et d’autres variantes.

Une seule règle: garder cela simple, car le second volet de la synchronisation va être difficile.

Synchrone ou asynchrone

Les différents types de synchronisation doivent tenir compte de la vitesse de l’information. Le transfert est synchrone lorsque les deux serveurs mettent à jour leurs informations au même moment. C’est typiquement le cas pour les virements: les deux banquent valident le virement bancaire simultanément, ou pas du tout. Il ne peut pas y avoir de temps «transitoire», au cours de duquel une banque a envoyé l’argent, et l’autre ne l’a pas encore reçu.

Asynchrone introduit un concept simple: le retard. Un des serveurs dispose de l’information, et il la relaie plus tard à l’autre. Il y aura donc une différence de temps entre ces deux opérations.

Le principal avantage de cette approche est d’éviter de transférer la charge du trafic à la ressource distante. Fondamentalement, lorsque les deux serveurs sont synchrones, toute sollicitation sur le premier se traduit par une sollicitation sur le deuxième serveur. Ainsi, le trafic du premier serveur sera transféré au second. Et, quand il s’agit de l’application Web, ce n’est pas une bonne idée.

Par ailleurs, le transfert synchrone signifie généralement qu’il se fait unité par unité. Chaque fois qu’un client met à jour ses informations de contact, l’information est envoyée au CRM. AU contraire, les systèmes asynchrones sont capables de travailler par lots. Au lieu d’envoyer les demandes unes par unes, le serveur d’origine accumule plusieurs demandes dans un lot: cela fait moins de sollicitations, et des traitements souvent plus rapides.

Des retards dans mon application!

Habituellement, lorsque le transfert asynchrone est présenté aux clients, il y a un peu d’incompréhension. Le concept est habituellement rencontré avec rejet: écoutez, j’ai besoin de ces données tout de suite! Toutefois, le cycle métier permet le plus souvent un léger retard. En fait, c’est acceptable la grande majorité du temps. Passons en revue quelques exemples.

La mise à jour de la description du catalogue est habituellement une routine quotidienne. Il est assez rare qu’elle doive être mise à jour plusieurs fois par jour. Les erreurs bénignes, telles que les fautes d’orthographe peuvent être corrigées manuellement, en ligne ; toute mise à jour d’importance, avec plusieurs modifications, ajouts et suppression peut attendre le prochain jour ouvrable. Traditionnellement, il est préférable de faire cette synchronisation la nuit, à faible trafic, afin de réinitialiser tous les caches sans pression. Solution: asynchrone, une fois par jour.

Les informations de contact ne peuvent pas souffrir d’attendre un jour. Une fois l’information a été modifiée, il est souvent important de la relayer rapidement au CRM. Toutefois, une différence de 5 minutes à 1 heure est toujours acceptable. D’une part, cela permet à l’utilisateur de changer d’idée en ligne, et changer de nouveau le contact, évitant un double envoi. Deuxièmement, il est rare d’avoir besoin des informations à la seconde dans le CRM. Même si le CRM est sur le point d’une diffusion importante, 5 minutes de retard n’auront pas un impact majeur : au pire, on omettra les quelques dernières informations, a mettre en rapport avec les milliers de contacts déjà transférés. Et si les contacts sont traitées manuellement dans le CRM, 1 heure est même délai normal de traitement: pas besoin de se précipiter. Solution: asynchrone, 5 à 60 minutes.

Les factures et de leur acheminement sont plus compliqués. L’expédition le jour même aura besoin des informations à flux tendu, et cela va nous empêcher d’utiliser un long délai de synchronisation. Un retard de 5 minutes sera acceptable, permettant à la fois le traitement par lots, et celui d’une commande de dernière minute. Pourquoi pas adapter la cadence pour être plus fréquent juste avant l’échéance, et plus espacé en matinée : la cadence peut être une fonction variable. Solution: asynchrone à fréquence variable, de 5 a 120 minutes.

L’inventaire est probablement l’une des seules situations qui nécessiteront une vérification synchrone. Vous ne souhaitez pas vendre un produit qui est en rupture de stock. Non seulement sa disponibilité doit être vérifiée, mais sa réservation doit également être confirmée. L’entrepôt gérera la situation, en envoyant un  ordre d’achat automatique en dessous de certains niveaux de stock, empêchant la vente de quelques articles avant qu’ils soient en rupture de stock, etc. Solution : synchrone.

La planification des capacités

La planification est plus simple pour les moteurs asynchrones que pour les synchrones. Fondamentalement, puisque le trafic est découplé de la synchronisation, vous pouvez dimensionner la taille de chaque opération. Idéalement, le traitement portera sur tous les objets en attente, et fera usage de toutes les commandes par lots disponibles sur le système distant. Pensez à la différence entre LOAD DATA INTO TABLE et INSERT INTO TABLE. Chaque fois que la charge est trop lourde pour le système distant, vous pouvez réduire la taille de chaque lot, ou, curieusement, les paralléliser (plusieurs mises à jour plus petites simultanément).

Quant au système synchrone, il n’existe qu’un seul espoir: rendre le système distant assez rapide. Pour cela, on doit estimer la quantité de trafic sur le Web qui sera reportée sur lui. En pratique, on peut utiliser une équation comme celle-ci:

Trafic * conversion * moyenne_hits * securite

Le trafic est ce que vous voulez: la circulation moyenne, les pics de trafic, etc. Idéalement, vous disposerez de tout à la fois, et ca sera le luxe.

La conversion est la partie de votre trafic qui va faire un appel à distance. Par exemple, votre e-boutique peut avoir 1000 utilisateurs par jour, mais fera 10 ventes par jour. Votre conversion est ici de 1 / 100.

Moyenne_hits est le nombre de hit que chaque session fera sur les serveurs distants. Par exemple, chaque vente contient habituellement deux produits. Il faudra alors 2 contrôles sur les serveurs distants. 2 est en fait une bonne évaluation ici.

La sécurité, facteur souvent négligé, couvre tous les problèmes imprévus. Ici, on peut s’attendre à des ventes soudaines. Cela fera 10 fois plus de commandes. Nous pouvons utiliser 10 comme sécurité.

Finalement, voici l’application de l’équation pour un trafic de 1000 visiteurs par jour, il faudra 1000 * 1 / 100 * 2 * 10 = 200 visites par jour sur le serveur distant. Si des pics de trafic 1000 visites par seconde sont attendus, nous aurons besoin de 200 requêtes par seconde sur le serveur distant.

Une fois que vous avez le trafic de cible pour le système distant, vous aurez besoin que ce système distant soit capable de répondre suffisamment vite. C’est un point extrêmement important, et, traditionnellement, il n’y a pas de contrôle fait. Avec le trafic de cible, vous pouvez exécuter un test de performances, et s’assurer que le serveur distant est convenable pour votre trafic et que les retards ne sont pas trop longs. La performance du système distant se reflétera directement sur votre site web e-commerce.

Conclusion

En conclusion, ne sous-estimez pas la synchronisation. Comme d’habitude avec l’informatique, de tels systèmes sont sujets à changement : il est évident qu’au début une réplication unidirectionnelle suffit, mais un hybride est rapidement mis en place, puis une synchro bidirectionnelle est demandée, et finalement, les performances se dégradent. Chaque phase a ses propres défis.

Les habitudes changent, et bien souvent, lorsqu’on cherche les coordonnées d’une société, ou les magasins d’une marque, le réflexe est de consulter directement le site web de la marque en question.

Le client potentiel cherchera instinctivement dans les liens de bas de site, dans les liens de haut de site, ou dans le plan du site pour trouver le lien providentiel du type « Contactez-nous », « Où nous trouver » ou « Nos magasins ». Ce petit lien est le sésame de la localisation du magasin le plus proche, heureux futur récupérateur du pouvoir d’achat (certes en baisse, mais pouvoir d’achat quand même !) du petit citoyen français désireux de contribuer à la croissance (qui a dit récession ?!) de la France et de ses entreprises.

Bref, le client cherche un magasin où dépenser son argent, et il le doit le trouver vite et bien.

Deux modules Bysoft à la loupe

Nous décrirons ici deux exemples de page « Où nous trouver » développées pour deux de nos clients.

Approche locale

Le premier module (développé pour Magento), est visible sur http://www.bergeredefrance.fr/index.php/nos-magasins/ et permet plusieurs visualisations :

-          Sélection directe d’un magasin dans les résultats de recherche (561 magasins à cet instant)

-          Sélection d’un département via la carte de France, ce qui a pour effet de filtrer les magasins affichés dans la liste de résultats, en n’affichant que les magasins du département choisi

-          Sélection d’un département via la liste déroulante

-          Suite à la sélection d’un département, possibilité de filtrer encore en choisissant une ville du département dans la seconde liste déroulante.

A noter que les résultats sont pré-chargés au chargement initial de la page, ce qui est donc un peu plus long au premier chargement, mais ensuite le filtrage des résultats est immédiat.

Lorsque l’internaute a trouvé le magasin qu’il cherchait, il peut cliquer sur le nom du magasin afin d’en visualiser les détails :

Sont affichés :

-          Une cartographie GoogleMap de localisation du magasin

-          Une photo du magasin

-          Un logo (soit de Bergère de France, soit du revendeur)

-          L’adresse du magasin

-          Les coordonnées téléphoniques

-          Les horaires d’ouverture

En BackOffice, le module permet de définir un type de carte par website (ou même par store-view). Il est donc possible d’avoir des cartes distinctes par website.

L’administrateur du site peut ensuite gérer l’ensemble de ses magasins grâce à une interface BackOffice :

Les champs descriptifs peuvent être surchargés en fonction de la vue magasin (pour le multilinguisme par exemple), et la mise en forme peut être faite, si besoin, directement en html.

Approche internationale

Le second module que nous vous présentons est plus orienté international, puisque la première étape est la sélection du pays dans une liste déroulante.

Une fois la sélection faite, un nouveau menu déroulant apparait, permettant la sélection d’un département (ou état, suivant le pays). Seul le champ « Pays » est obligatoire, donc le client pourrait directement cliquer sur le bouton « Rechercher » pour afficher l’ensemble des résultats.

Si le client sélectionne un département, une nouvelle liste permet encore de filtrer les résultats en choisissant une ville.

Un clic sur le bouton « Rechercher » affiche alors les résultats de la recherche :

Les informations suivantes sont affichées dans cette liste :

-          Nom du magasin

-          Coordonnées

-          Logo/Photo

Un lien « voir les détails » permet de visualiser les informations complémentaires (horaires d’ouverture, Site web…) ainsi qu’une carte de localisation GoogleMap :

En BackOffice, l’interface est comparable à celle du module précédent :

Autres exemples

Voici d’autres exemples de modules de localisation développés pour nos clients, en fonction de leurs problématiques métier :

http://www.bourrelier-education.fr/index.php/contact/index/delegues/

http://www.dekra-industrial.fr/La-societe/Choisissez-votre-Contact-DEKRA-sur-la-carte

http://www.agglo2rivesdeseine.fr/index.php/fre/Rayonnement-economique/Les-zones-d-activite-de-la-CA2RS

http://www.cultureindoor.com/

http://www.pacificpeche.com/27_magasins/

Une étude intéressante réalisée par une entreprise B2C en chine explique l’intention d’achat des Chinois :

“48,3% des internautes chinois achètent en ligne parce qu’ils pensent gagner du temps, ” 31,5% achètent en ligne par curiosité et pour la facilite d’utilisation “et” réduire les coûts (38,8%) ” Ce sont les principales raisons après le ” Saving Time “.

Voyons ensemble quels sont les principaux modules de paiement chinois :

-          Alipay

Alipay, une filiale du groupe Alibaba, est la plus populaire plate-forme tierce de confiance de paiement en ligne en Chine. Outre Taobao et Alibaba.com, Alipay fournit des solutions de paiement en Chine auprès de plus de 550 000 commerçants pour la vente en ligne (jeux virtuels, les produits numériques, les services commerciaux, les billetteries et opérations d’utilisation de paiement des frais).

Alipay fournit un service de paiement, au moyen duquel les consommateurs peuvent vérifier s’ils sont satisfaits de leurs acquisitions avant de régler la transaction au vendeur.

Alipay a environ 65 partenaires financiers (banques nationales en Chine, MasterCard, Visa, BEA). Ce module facilite les services off-line à valeur ajoutée grâce à des partenariats stratégiques avec China Post, qui a la couverture des zones rurales et les campus universitaires, et les magasins de proximité ouverts 24/ 24 heures.

-          Tenpay

Tenpay est le concurrent direct d’Alipay. Ce module populaire a été développé par Tencent, qui détient QQ.com (environ 300 millions d’utilisateurs).

Tenpay permet aux entreprises et aux particuliers d’effectuer et de recevoir des paiements Online sécurisés. Il est aussi possible de recharger son téléphone mobile avec ce module. Il est compatible avec le service e-banking des principales banques. La part de marché de Tenpay est passée de 10% en 2006 à 20,5% en 2009. En 3 ans, la part de marché de Tenpay a donc augmenté de 10,5%, contre 21,2% d’augmentation de part de marché pour Alipay.

Aussi, en 2009, la part de marché de Tenpay a augmenté de 1,3% tandis que son principal concurrent Alipay a seulement augmenté de 0,3%.

-          Chinapay

ChinaPay, une branche de China UnionPay (soutenu par le gouvernement du réseau de transfert inter-bancaire), créée en 2000, est également un module de paiement en ligne. Grâce au soutien financier et la promotion de China UnionPay, ChinaPay est utilisé pour les paiements de factures en ligne, services de courtage en ligne, services bancaires, et bien sûr de simples paiements en ligne. La part de marché de ChinaPay a légèrement diminué durant les trois dernières années.

Ci-dessous les autres modules de paiement chinois:

-           99Bill

-           ChinaPnR

-          YeePay

-           IPS

-          ChinaBank

-           PayEase

Ce graphique met en exergue la réalité du marché des modules de paiement chinois :

Pour le commerce électronique, un site Internet doit établir un accord avec plusieurs banques différentes afin d’accepter tout paiement en ligne provenant des utilisateurs.

Ces plates-formes tierces de confiance de paiement en ligne exposées ci-dessus sont très utiles pour les détaillants. En effet, en tant qu’e-commerçant vous devez examiner les nécessités primaires de vos clients afin de mettre en place un module de paiement effectif.

Vous ne serez pas en mesure d’avoir un site e-commerce sans une plate-forme du tiers payant en ligne.

Une autre chose importante à retenir est que les transactions en ligne par carte de crédit sont limitées avec chaque banque. Un compte électronique pourrait être financé par un prélèvement électronique à partir d’un compte bancaire ou par carte de crédit au choix du payeur. Désormais, les banques commencent à exiger un compte bancaire vérifié afin que le titulaire du compte ne dépasse une limite de dépenses préétablie.

Maintenant,  a vous de choisir votre meilleur module de paiement chinois!

« Release early, release often »

Cela s’apparente à la stratégie « Release early, release often »: déployer souvent montre que le projet progresse. Ces progrès ne sont pas toujours importants : parfois même, des bugs sont publiés. Mais durant la période de développement, c’est une situation normale. De toutes manières, une nouvelle version corrigera bientôt le problème. Et puisque le bug a été identifié tôt dans le processus, il sera donc plus facile à corriger, et aussi, plus important, plus facile à pardonner.

Toujours pas fini…

Comment peut-on fournir un code qui puisse toujours être mis à disposition ?

Eh bien, tout d’abord, entre la version et le code actuel, il ya une pièce d’ingénierie appelée SMC: Git, SVN, Mercurial, fossiles, CVS …( appelez cela comme vous voulez !), qui sera la principale source pour la version. Tant que vous ne commitez pas dans le SMC, votre code ne peut pas être publiable: il peut ne pas être compilé, ni être propre, ou non fonctionnel. Tant qu’il n’est pas commité,  le code n’existe pas.

Une fois qu’il est commité, il doit faire partie intégrante de l’application. Et pour être publiable, il ne doit pas casser l’application. La première vérification sera la compilation par PHP : si le code n’est pas compilé, alors, il ne sera pas publiable.

Développement bouchon de champagne

Le codage total, jusqu’à ce qu’il fonctionne, est aussi appelé le développement bouchon de champagne : vous ne savez le son que fera le bouchon de bouteille de champagne qu’à son ouverture. A ce stade, vous aurez eu soin d’avoir tous vos amis autour de vous, parce que si le bouchon saute, alors vous voudrez remplir quelques verres et trinquer. Par contre, si cela échoue, tous vos amis seront là pour vous remonter le moral ou se moquer de vous (oui, les amis font aussi cela).
Cette allégorie peut être appliquée au développement : quand le code est attendu depuis trop longtemps, les attentes s’accumulent, et commencent à grandir, jusqu’à devenir extrêmes. Puisque vous vous concentrez que sur le code, et laissez les utilisateurs dans le noir, alors ils trouveront les informations avec leur seul outil à leur disposition : l’imagination. Voilà comment vous vous retrouvez avec un beau projet, bien en deçà des attentes.

Largeur d’abord

L’autre approche est de rendre le code prêt dès que possible, même s’il n’est pas complet. Compiler est une première étape. Le fonctionnement complet n’est seulement que le troisième niveau. Entre les deux, vous avez le niveau «incomplet» : il fonctionne mais pas entièrement.

Prenons un exemple : comment travailler sur un module imaginaire de Drupal addressbook et l’avoir  fonctionnel pendant tout le dévelopement ? Si un tel module nécessite de plusieurs jours de travail, alors il ne fonctionnera pas entièrement les premiers jours. À ce stade, il n’est pas important de l’avoir entièrement opérationnel : nous voulons juste qu’il fonctionne.

Imaginez le stade précoce du module Drupal: le module lui-même est créé, basé sur son nom, avec beaucoup de « hooks » vides. Cela va compiler mais ne fera rien. Cependant, cela est publiable : il peut être envoyé sur une nouvelle version et n’ajoutera rien … à l’application finale.
Puis, à partir de cette base, vous pouvez commencer à ajouter de nouvelles pièces. Imaginez que vous travaillez sur le carnet d’adresses.

Vous avez alors différentes possibilités pour commencer à travailler : vous pouvez commencer à partir de la structure de la base de données et de mettre à jour hook_install ; puis ajouter quelques valeurs dans la base de données, et enfin travailler dans hook_view, de sorte que vous pouvez fournir une vue sur les données existantes, puis le même hook_view pour un formulaire requérant des données.
Vous pouvez également démarrer à partir hook_menu pour afficher le menu et un accès à votre nouveau module, puis  hook_view pour l’afficher. Enfin hook_install pour ajouter une nouvelle CSS au système de modèles. Vous pouvez aussi commencer par le panneau d’administration, les modèles, etc…
Chacune de ces approches vous donnera quelque chose de fonctionnel : vous et les utilisateurs seront en mesure d’exécuter cette application, et de voir le travail effectué ; bien sûr pas tout entièrement : le développement n’est pas encore fait mais seulement une partie.
C’est la principale différence avec le développement en profondeur. Une approche en profondeur résoud tous les problèmes qui se présentent : Drupal hooks, structure de la base de données, modèle, tests et déploiement. À tout moment, c’est un travail en cours et et rien n’est publiable : ce qui est fait est bien fait, mais on ne peut le faire marcher.

En fin de compte il ya deux approches différentes pour que cela soit toujours publiable.

• Croissance organique du code : commencer par déposer tout le code requis pour le faire fonctionner. Ensuite, ajoutez nouvelle fonctionnalité au dessus d’un tel code. J’appelle aussi cela « ajouter de la chair autour de l’os », basé sur le cliché du squelette. Vous finirez probablement avec beaucoup de fonctions vides ou constantes, qui seront des emplacements, ou « placeholders » pour un code plus complexe et ultérieur. Compter le nombre de ces emplacements est un bon indicateur des progrès réalisés.

• Code visible : cette approche est centrée sur les utilisateurs (ou clients, si vous préférez) . Ne travaillez que sur ce qui est visible. Ce formulaire de 120 champs ne commencera qu’avec deux formulaires. Puis, il affichera 3, puis 4, puis 12, puis 30, etc … A chaque fois, il va ajouter de nouvelles fonctionnalités. Et si c’est un tunnel  de paiement en 12 étapes, alors il devrait commencer par 1 étape de paiement, puis 2, etc … Gardez à l’esprit que les utilisateurs ne mesurent la progression que sur ce qu’ils voient (c’est-à-dire la vue), et non sur la quantité de travail ou de code que vous fournissez.

Si vous prévoyez de garder votre code publiable, vous devrez être en mesure de répondre à cette simple question : puis-je simplement déployer mon code maintenant ?

Cela vous rendra prêt pour n’importe quelle situation pouvant survenir en dehors  du planning : problème de sécurité, publication en urgence pour démonstration, changement soudain dans le planning client, ou même, un changement de développeur. Un code qui fonctionne bénéficiera toujours  à la personne suivante, plutôt qu’elle se batte avec un ensemble de tâches partiellement achevées.

Damien Seguy

Depuis, la liste des fonctionnalités mises en place dans le cadre de ce projet se sont quelque peu précisées et l’étendue de l’écosystème X-commerce commence à se dévoiler.

Une grande part du projet est consacrée à la mise en place d’API afin de faire émerger une véritable communauté de développeurs.

Ces API concerneront des domaines aussi divers que le système de paiement, la recherche, les stocks ou les outils de prospection marketing.

Concernant le paiement,  deux API sont mises à disposition des développeurs pour l’authentification et la facturation et s’appuieront sur le système Paypal. Ce n’est pas une nouveauté, mais ça va permettre de systématiser encore davantage ce mode de paiement pour les pros.

X-Commerce va resserrer les liens entre l’e-commerce et le commerce réel et local avec deux API : La disponibilité en stock locale grâce l’API Milo Open et la recherche locale de produits ou de boutiques grâce l’API Where.com. Ebay semble miser gros sur le shopping local, mais également sur le mobile…

En effet, le point faible des applications mobiles e-commerce actuelles est le nombre limité de moyens de paiement.

Mobile Express Checkout va permettre de simplifier le paiement via un telephone portable ou une tablette. Compatible avec Windows Phone, Ipad, Iphone, Blackberry et Android, Paypal Mobile Express a l’ambition de devenir le moyen de payement incontournable de l’acheteur nomade, le tout de manière toujours aussi sécurisée.  Le paiement mobile est actuellement l’un des points faible de Magento en version Mobile. Les problèmes de compatibilité pour chaque plateforme sont encore nombreux.  Grâce à l’API mise à disposition des développeurs, l’internaute n’aura plus besoin de sortir de l’application pour effectuer son paiement. La fluidité de la transaction s’en voit donc renforcée.

Au niveau des outils marketing,  X-commerce propose des fonctionnalités de recommandation de produits, de Ciblage des meilleurs acheteurs (via le Paypal Identity Cookie), un outil de segmentation de la clientèle (Segmentation Service API, toujours via Paypal)…

Grande Nouveauté : Open Ebay Apps Permet de lier son application e-commerce (de préférence Magento, mais pas seulement) directement à Ebay. Il n’est pas encore précisé si il y aura partage des identifiants entre la plateforme et les applications tierces ou pas.

D’autres API sont proposées dans le cadre de l’écosystème :

Magento Go : L’application mobile de Magento est mise en avant par Ebay, pour les petits e-commerçants, qui ont longtemps été l’un des cœurs de cible de la célèbre place de marchés.

Best Match : permet d’optimiser la recherche sur les applications e-commerce, à l’image de ce qui existe sur Ebay.

Client Alerts : Permet d’informer les utilisateurs de la plateforme Ebay d’un évènement Marketing ou Commercial.

Fabric : C’est l’outil de communication entre les différents plugins. Les extensions ne communiqueront plus entre elles directement, mais via le centre d’interactions Fabric.

Feedback :  A l’instar de ce qui existe sur Ebay, ce système permet de gérer les notations détaillées attribuées aux vendeurs. Cela est censé permettre aux vendeurs de repérer et agir sur leurs faiblesses (livraison, communication, rapidité, prix…).

Resolution Case : C’est un outil qui n’existait que sur Ebay, et qui est maintenant mis à disposition des applications e-commerce tierces.

Shopping API : C’est l’application permettant d’intégrer Ebay dans une application tierce. Elle permet d’afficher les données publiques d’Ebay, telles que les produits ou les informations sur un marchand.

Trading API : C’est  l’application permettant de récupérer les données privées d’Ebay, telles que les ventes, les  informations après-vente, les informations utilisateurs…

Bref, X-Commerce est en réalité une extension des fonctionnalités de Paypal et d’Ebay mises à disposition de Magento et d’autres applications tierces.

Il est assez  vraisemblable que Magento Go intègrera rapidement la plupart de ces fonctionnalités par défaut.