Magento 2 à l’essai ! Conférence Bargento 2015 par les experts Magento de l'e-Commerce Academy

Tél. 01 45 63 19 89
contact@ecommerce-academy.fr
EXPERTS MAGENTO
intervenants

MÉTIERS
Devenir e-Commerçant
Gestion & pilotage
Webmarketing | Ergonomie
Référencement
Google Adwords | Analytics
SOLUTIONS
Magento
Prestashop
Drupal Commerce
Oxid eSales
RBS Change
e-Commerce Academy

SOMMAIRE
Magento 1 Vs. 2 : changements techniques
Magento 2 : changements fonctionnels
Magento 2 : organisation & écosystème
Magento 2 : bilan & roadmap
1
2
3
4

MAGENTO2:changementstechniques
Définitionstructurelle
Module
un socle technique presque autonome,
modulaire
un socle technique autonome,
modulaire
Magento 1 Magento 2
Framework

Définitionstructurelle
Module
Mage_CatalogInventory
Module Mage_Core
(contient le Framework
Magento)
Lib
(ZF1, Varien,...)
Module
Magento_CatalogInventory
Lib Magento_Framework
séparé
Vendors (ZF1,
Composants SF2,...)
schéma de dépendances simplifiées
Magento 1 Magento 2

MAGENTO 2 : changements techniques
Différences Structurelles
Catalog
(1.x & 2.x)
Bundle
(1.x)
Downloadable
(1.x)
Configurable
Product
(2.x)
Layered
Navigation
(2.x)
Grouped
Product
(2.x)
•• correction des problématiques de
modularités (disparition du module
Mage_Adminhtml)
•• dossier dédié pour le framework
Magento 2
•• plus de classe toute puissante ‘Mage’
•• granularité de modules plus fine sur
Magento 2
•• utilisation des namespaces de php
5.3

Choix de conception structurants pour Magento 1
patterns 1.x
•• logique MVC
•• config XML
•• convention de nommage ZF1
•• pattern events/observers
•• active record
•• implémentation d’un mécanisme de rendu de vue spécifique
(layout / block / template)

patterns 2.x
•• logique MVC
•• config XML
•• respect des standards PSR 1, 2, 3, 4 (code style, autoload,…)
•• di (injection de dépendance)
•• pattern SOLID (Single Responsability, Open Closed Principle, Substitution de Liskov, Ségrégation des Interfaces, Inversion
de dépendances)
•• amélioration du mécanisme de rendu de vue (layout / block / template) de Magento 1
•• code Generator (permet d’utiliser d’autres patterns – proxy, interceptors, …)
•• dossier publique dédié pour les ressources WEB
•• tests (pas seulement unitaires)

Comparatif volume de sources Magento 1 & 2
MAGENTO 1 MAGENTO 2
Nombres de modules 65 98
Nombre de fichiers (sans var et media) 13.091 33.982
Nombre de dossiers (sans var et media) 4.866 13.684
Nombre de classes total 7.187 16.556
Dont core Magento 4.503 8.067
Dont lib 2.653 (90% ZF1) 2.131
Dont vendors NA 6.358
Nombre de lignes de codes 1.321.898 2.518.730
Dont core Magento 740.629 1.106.711
Dont lib 578.791 (90% ZF1) 269.594
Dont vendors NA 1.142.425

Comparatif structure de la base de données Magento 1 & 2
MAGENTO 1 MAGENTO 2
Nombre de tables 341 324
Nombre de colonnes 3006 2706
Nombre de contraintes d’intégrité 450 389
Nombre d’indexes 723 612
Nombre de triggers 0 (CE) (approx 10 EE) 0 (CE) (?? EE)
Utilisation de l’EAV OUI OUI

Changements sur les tables des entités catalog
•• catalog_product_entity_
media_gallery_value_to_entity
•• catalog_product_entity_
media_gallery_value_video
•• catalog_url_rewrite_
product_category
•• catalogsearch_fulltext_
index_default
•• tables d’index temporaire
(ex. : catalog_category_anc_categs_index_idx)
•• catalogsearch_query
•• catalogsearch_result
•• catalogrule_affected_product
•• catalog_product_enabled_index
tables catalog*
ajout / suppression

Changements sur les tables des entités customer
•• customer_log
•• customer_visitor
•• customer_grid_flat *
*la table customer_grid_flat permettra d’optimiser les opérations d’affichage en
grille sur les entités clients, dans l’admin
•• aucune
tables customer*
ajout / suppression

Changements sur les tables des entités sales
•• renommage des tables
sales_flat en « sales »
ex. : sales_flat_order > sales_
order
•• ajout des tables sales_sequence_
profile et sales_sequence_meta
•• sales_recurring_profile
•• sales_recurring_profile_order
•• sales_billing_agreement
•• sales_billing_agreement_order
tables sales*
ajout / suppression

Bilan comparatif volumes de sources et bases de données
•• single responsability => création de plus de classes
•• inversion de dépendances => créations d’interface
•• base de données : pas de changement notables
Les problématiques de multiplication de fichiers viennent principalement de
l’implémentation du pattern SOLID :

Config Magento 1
•• on réalise une configuration via le
fichier quasi exclusif config.xml dans
le module Magento en question qui
définit chaque composant technique
du module
•• on crée un fichier de déclaration de
modules dans app/etc/modules
pour indiquer à Magento que le
module est actif
fonctionnement global 1.x

Config Magento 2
•• un fichier de configuration pour chaque niveau de couche
technique doit être créé
•• on active le module via l’outil console Magento (dans le dossier
bin) pour qu’il soit pris en compte
fonctionnement global 2.x

ConfigMagento2

Comparatif configuration Magento 1 & 2
MAGENTO 1 MAGENTO 2
Documenté (par des tutoriaux) (tutoriaux & officielle)
Validation (Xsd, dtd)
Structure de tags fixes
Lourdeur de mapping
Fichier de configuration
unique
presque (historiquement
tout était dans config.xml)
Levée d’erreur en cas de
faute de syntaxe

Couche controller Magento 1 : routage
•• respect d’une convention de structure d’url du ZF1 qui veut que les trois premiers
éléments du pathinfo soient dédiés au routage de la requête
•• association d’un frontName (premier élément du pathinfo) à un module dans la
configuration pour déterminer si un module gère une requête HTTP
routage requêtes http 1.x

Couche controller Magento 1 : éxécution de l’action
Classique :
•• implémentation de la classe de
controller : en général un controller
par Entité
•• ou IndexController s’il n’y a pas
d’entités associées
•• puis, implémentation de méthodes,
notamment des « actions »
Exécution de l’action 1.x

Couche controller Magento 2 : routage
•• respect d’une convention de structure d’url du ZF1 qui veut que les trois premiers
éléments du pathinfo soient dédiés au routage de la requête
•• association d’un frontName (premier élément du pathinfo) à un module dans la
configuration pour déterminer si un module gère une requête HTTP (idem Magento 1
mais configuration différente)
routage requêtes http 2.x

Couche controller Magento 2 : exécution de l’action
•• une classe de controller par Action
•• implémentation d’une méthode « execute »
Exécution de l’action 2.x

Bilan comparatif couche controller M1 Vs. M2
•• les couches controllers Magento 2 et 1 sont quasiment identiques
en terme de volumes d’implémentation
•• il n’y a plus de dossiers multiples (controllers et Controller)
•• granularité plus fine des classes de controller (Single responsability
pattern ?), donc plus simples à étendre.
Bilan comparatif controller

CouchemodèleMagento1
Resource
Collection
Entité
(Model Abstract)
DATABASE
Schéma couche
modèle Magento 1

CouchemodèleMagento2 Schéma couche
modèle Magento 2
SERVICES INTERFACES
SERVICES IMPLÉMENTATIONS
Service Manager
Interface
Service Manager
Entité
(Model Abstract)
Data Model
Interface
Data Model
Resource
Service Repository
Interface
Service Repository
DATABASE

Le mieux sur la couche modèle Magento 2
•• une vraie couche service
•• pattern inversion de dépendance (les appelants ne doivent utiliser
que les interfaces mises à disposition)
•• réduction de duplication de code (couche commune à tous les
canaux d’appel)
•• réduction des problématiques de compatibilité ascendantes
(puisque Magento s’engage à ne pas changer l’implémentation de
ses services sauf changement de version majeure)
Magento 2 Vs. Magento 1
Bénéfices :

Le moins bien sur la couche modèle Magento 2
•• une plus grande lourdeur car plus de classes à implémenter (donc plus de code)
•• des choix de l’éditeur pas encore complétement clairs
Mais...

LemoinsbiensurlacouchemodèleMagento2
Cinématique
CustomerRepository::save
Début
(Input Data Model)
Fin
(Output Data Model)
1. Validate Data Model
6. Mapping Abstract Model > Data Model
3. Abstract Model Save
2. Mapping Data Model > Abstract Model
5. Push Abstract Model To Registry
4. Validate Abstract Model In Resource

Couche setup Magento 1
•• inscription du numéro de version du
module dans le fichier config.xml
•• création d’un fichier de setup (sql ou
data) par chaque version du module
•• les versions des modules installés
sont stockés dans la table core_
resource
•• les scripts de setup sont exécutées
à chaque initialisation de l’application
Magento
couche setup 1.x

Couche setup Magento 2
•• inscription du numéro de version du module
dans le fichier module.xml
•• création des setups dans les classes
InstallData, InstallSchema, UpdateData,
UpdateSchema
•• les versions des modules installés sont
stockés dans la table setup_module
•• les setups sont exécutés via l’outil console
mis à disposition par Magento php bin/
magento setup:db*
couche setup 2.x

Bilan comparatif couche setup M1 Vs. M2
Les avantages Magento 2 sur l’organisation des setups se situent sur :
•• l’exécution en ligne de commande de l’installation/mise à jour qui
permet d’éviter des mises à jours concurrentes et de les exécuter à
la demande
•• la gestion de sources simplifiées en évitant la multiplication des
fichiers de setup
Bilan comparatif setup

Couches vue Magento 1 (côté backend)
Magento 1 a découpé son mécanisme de rendu de vue en 3 couches :
•• blocks : classes php qui ont pour responsabilités
1 - l’affichage
2 - l’implémentation de récupération de données
•• layout : fichiers xml qui pilotent l’instanciation des blocks sur les pages
•• templates : fichiers phtml associés à des blocks qui permettent l’affichage des
données
Mécanisme de rendu
de vue 1.x

CouchesvueMagento1(côtébackend)
STEP 1 : Mise en mémoire des blocks
Instancie
STEP 2 : Affichage
CONTROLLER
Layout
Blocks
Blocks
Template

Couches vue Magento 2 (côté backend)
•• les fichiers de layout et templates sont inclus directement dans un dossier view du
module et non plus dans les themes base/default ou default/default
•• il y aura un fichier de layout par page à modifier et non plus un fichier de layout
global par module, de plus les fichiers de layout sont validés par des xsd
Mécanisme de rendu
de vue 2.x

Couches vue Magento 2 (côté frontend)
Magento 2 fournit des thèmes responsive « blank » et « luma » HTML5/
CSS3, il s’agit de RWD « mobile-first approach »
jQuery devient le framework JS natif, ceci évitera les doubles
implémentations jQuery + prototype qui alourdissent les pages
implémentation de RequireJs, assurant une gestion de dépendances entre
JS pour des temps de chargements optimisés
LESS CSS, langage css dynamique, permet de simplifier la maintenance css
et réduire le poids des feuilles de style

Changements sur les tables des entités catalog
•• les fichiers de layout séparés
par page (plus intuitif pour les
intégrateurs)
•• framework JS moderne
•• processeur CSS (LESS)
•• possibilité de compiler Less
coté serveur et/ou client
(fonctionnalité native LESS)
•• davantage de prérequis techniques
bilan comparatif vue
avantages / inconvénients

Couche shell Magento 1
2 possibilités pour créer un script CLI :
•• un script « maison » avec comme en-tête •• un script posé dans le dossier shell étendant
Mage_Shell_Abstract
couche shell 1.x

Couche shell Magento 2
Pour créer un script CLI Magento 2, il faut :
•• créer une classe étendant SymfonyComponentConsoleCommandCommand
qui idéalement appelera le service contract responsable de l’exécution du
traitement
•• enregistrer cette classe dans la DI, elle sera ensuite disponible dans la console :
couche shell 2.x

API Magento 1
l’implémentation concrète de l’API Magento est :
•• webServices appelables via SOAP
•• webServices appelables via REST
pour chaque protocole de Webservice, il faut :
•• prendre en compte l’authentification spécifique, et créer des comptes user ws
correspondants (pour SOAP)
•• gérer des rôles spécifiques REST et SOAP
•• écrire la logique métier pour chaque canal d’appel (dossier API pour SOAP,
dossier API2 pour REST)
•• créer la configuration correspondante, pour mapper les paramètres de l’url avec
le service sélectionné

API Magento 2
l’implémentation concrète de l’API Magento est :
•• webServices appelables via SOAP
•• webServices appelables via REST
pour chaque protocole de Webservice, il faut :
•• la signature des interfaces DataModel permettent de construire la signature des
services (wsdl)
•• écrire la configuration dans la DI

API Magento 2
Les avantages de l’implémentation de l’API Magento 2 sont :
•• il n’est plus nécessaire de ré-implémenter la logique métier pour chaque protocole,
puisqu’on passe par la couche service
•• authentification unifiée
•• gestion de rôles unifiée

MAGENTO 2 : nouveaux patterns
Pattern « injection de dépendance »
Ce mécanisme est fondamental car il architecture l’ensemble
de l’application M2, il fonctionne ainsi :
•• on définit l’ensemble des dépendances d’une classe en tant que propriétés
•• ces dépendances sont ensuite configurées dans le fichier di.xml
•• elles sont ensuite injectées via un « ObjectManager » dans le constructeur de la classe au
moment de son instanciation

•• on peut créer de vrais tests unitaires, en injectant des mocks à la
place des dépendances
•• on évite les dépendances cycliques
•• on réduit les couplages entre les classes, ce qui permet une
meilleure extensibilité et modularité
avantages

•• plus lourd à écrire et à configurer (10% de temps en plus en
moyenne par rapport à une application sans DI)
•• au moment d’instancier une classe, toutes les dépendances sont
chargées (ce qui est plus lourd à l’exécution)
•• avec la combinaison d’une implémentation SOLID (plus de classes),
cela rend plus important la compilation.
inconvénients

Pattern « Code Generator »
Le Code Generator de Magento 2 permet de générer à la volée, ou
pré-générer, des classes sans les écrire :
•• les fichiers générés sont dans le dossier var/generation
•• la liste des patterns couverts est :
•• à noter que seul le pattern Interceptor requiert vraiment un mécanisme de Code Generator.

Pattern « Interceptor »
Le but du pattern Interceptore (ou POA programmation orientée aspect)
est de séparer les implémentations métiers des dépendances
techniques (ex. : logger).
Dans Magento 2, on définit un plugin dans la DI :
qui va implémenter les méthodes autour duquel il va se plugger :

Pattern « Interceptor »
•• plus besoin de déclencher et de chercher un event à un moment
précis (en général before ou after….)
•• code plus lisible
•• code plus difficile à déboger
avantages
inconvénients

Pattern « Factory »
Le pattern factory est un pattern qui prend en dépendance une
classe de model entité et qui se charge de la construire.
Il permet de résoudre une des problématiques du DI, qui est qu’on ne peut passer en dépendance
directe une entité model (à cause du contexte) alors qu’une factory le peut.

Pattern « Proxy »
Le pattern proxy ne prend en dépendance que l’ObjectManager et
implémente chaque méthode de l’objet « proxifié »
Dès qu’on appelle une méthode sur le proxy, il instancie l’objet « proxifié » et appelle la
méthode concernée. Il permet de résoudre les problématiques suivantes :
•• lourdeur d’injection de dépendance
•• faire passer des dépendances cycliques (même si c’est peu élégant)

Choix de conception structurants pour Magento 1 & 2
•• les patterns utilisés par Magento 2 sont plus modernes & inspirés de Symfony 2
•• sur le papier, un développement sur Magento 2 apportera donc plus de sécurité
(dossier publique web dédié), et plus de robustesse (prise en charge native des tests
unitaires)
•• toutefois une plus grande séparation de fichiers et une multiplication des patterns
peut alourdir l’applicatif et posera une barrière à l’entrée supplémentaire pour travailler
sur M2 (« pattern overdose » ?)
Bilan

MAGENTO2
ChoixdeconceptionstructurantspourM2
Suite de tests
automatisés
Performances
Obsolescene
(code 1.x)
unitaires
(fonctions)
Statiques
(qualité)
Intégration
(produit)

MAGENTO 2
•• une des principales nouveautés de Magento 2 est
la présence de tests automatisés
•• un des intérêts des changements techniques apportés
est d’avoir rendu le socle Magento 2 :
•• nativement testable
•• nativement testé
•• donc cohérent avec le positionnement « Enterprise »

MAGENTO 2
Fonctionnalité : remarques préalables
•• pour le moment les changements fonctionnels sont légers, les évolutions
seront apportées à partir de 2016
•• en tant qu’application e-Commerce, le périmètre fonctionnel de Magento
est de toute façon borné
•• Fonctionnalités les plus demandées au MLUK 2014
(extrait, sur 628 votes)
113
83
76
64
62
0
20
40
60
80
100
120
Import/export
CMS
Staging
Reporting
Recherche
113
83
76
64 62

MAGENTO 2
Fonctionnalité : gestion du cache
•• le full page cache devient natif en CE :
•• interne via Redis (ou filesystem, …)
•• externe via Varnish 3 ou 4
•• la gestion de cache public vs. privé est assurée en FPC comme avec Varnish (ESI)
pour délivrer un haut % de pages via le FPC
Gestion du cache & FPC

MAGENTO 2
Fonctionnalité : gestion du cache
•• logique d’invalidation fine du cache (par tags)
mais pas de correction sur les tags liés au layout
•• « bug » déjà identifié en EE 1.13 :
l’intégralité du FPC est toujours vidé au passage de commande
•• techniquement, tout était déjà possible et/ou fait en 1.x,
mais l’intégration native en 2.x réduira les temps et les coûts d’implémentation
Gestion du cache & FPC

MAGENTO2
Fonctionnalité:gestiondesindexes
Sauvegarde produit lente ?
$product->save();
save EAV
cleanCache BS
cleanCache AS
indexation
divers
save EAV
4%
cleanCache BS
8%
cleanCache AS
8%
indexation
76%
divers
4%

MAGENTO 2
Fonctionnalité : gestion des indexes
•• le « principe » des indexes EE 1.13 devient natif en CE 2.x :
l’indexation manuelle est remplacée par l’indexation asynchrone
par tâche planifiée (cron) ou à la sauvegarde
•• l’indexation partielle devient native
•• à date pas de plan d’alternative à EAV
•• techniquement, tout cela était déjà possible en 1.x,
mais l’intégration native en 2.x devrait limiter le spécifique
Gestion des indexes

MAGENTO 2
Fonctionnalité : gestion des indexes
•• Enterprise : séparation possible en 3 bases de données
Catalog, Checkout, Order Management (chacune pouvant avoir
un slave associé)
•• Enterprise : file d’attente pour rendre asynchrone l’insertion de
commandes et la mise à jour de stocks (RabbitMQ)
•• Enterprise : d’après les meilleurs benchmarks disponibles le
nombre de commandes/h passerait de 42k en 1.x à 90k en 2.x
(non vérifié)
Gestion des indexes

MAGENTO 2
Fonctionnalité : performance toolkit
•• une suite de générateurs pour
simuler des volumes (products, orders, ...)
•• une suite de tests basés sur Jmeter pour
mesurer et suivre les performances
•• permet en natif et vérifier les performances de
comportements clés : ajout panier, recherche, checkout, ...
Performance toolkit

MAGENTO 2
Fonctionnalités : interface d’administration
Illustration vidéo à retrouver sur http://acd.my/support-magento-2-slide-63

MAGENTO 2
Fonctionnalités : Checkout
Illustration vidéo à retrouver sur http://acd.my/support-magento-2-slide-64

MAGENTO 2
Fonctionnalités : import/export (Dataflow supprimé)
améliorations sur l’import/export de Configurables
permettant notamment de créer des produits associés
« à la volée » par des champs « configurable_variations* »
améliorations sur l’import/export de Customer permettant
notamment de gérer les adresses
En import, les performances seraient améliorées (100k simples en 25 min, non vérifié).
L’interface d’export est cependant toujours aussi peu ergonomique.
améliorations sur l’import/export de Bundle
Customer
ImportExport
Bundle
ImportExport
Configurable
ImportExport

MAGENTO 2
Fonctionnalités : outils de développement et monitoring
support applicatif au monitoring avec New Relic permettant la
remontée de « custom parameter » (notamment cache flush,
place order, config, catalog, concurrent users/admin, …)
outils de « publication » des fichiers « statiques » (design,
traductions) accessible par la console
outils de développement accessibles par la console (publication
des css, débogage, …)
nouveau module de paiement mobile associé à Paypal
(forcément !)
New Relic
Deploy
Developer
Braintree

MAGENTO 2
Fonctionnalités : catalogue, recherche, …
fonctionnalité « légère » de gestion de vidéos associées aux
produits
module de gestion « abstraite » de la recherche, dont l’objectif est
de permettre la recherche par d’autres modules (par exemple,
CMS) ; il est cependant encore adhérent à CatalogSearch
module dédié permettant de personnaliser les modèles de
numéros de commandes, factures, remboursement, bons de
livraison
nouveau module dédié aux données de test, permettant leur
installation et suppression par la console
Product
Video
Sales
Sequence
Sample
Data
Search

MAGENTO 2
Fonctionnalités : ???
Version

MAGENTO 2
Fonctionnalités : ???
Version
?

MAGENTO 2
Fonctionnalités : Migration tool
•• un outil de migration de données est fourni pour migrer de M1 vers M2,
il couvre le natif et sera à étendre pour la migration des tables/colonnes spécifiques
•• cet outil est prévu pour être compatible avec CE 1.7+ et EE 1.11x,
à la condition que la version M1 de départ soit « conforme aux standards »
•• son usage sera une des nombreuses étapes dans le cadre d’une migration,
la plus importante étant en amont sur la phase d’analyse / audit
•• à part les éléments de design personnalisés créés dans l’admin, et la gestion des droits admin et api,
il couvre l’intégralité des tables/colonnes natives
•• disponible sous forme d’un package composer à
http://packages.magento.com/#magento/data-migration-tool

MAGENTO 2
Fonctionnalités : Magento Connect
http://packages.magento.com/

MAGENTO 2
Organisation des ressources
Pour tirer pleinement parti des nouveautés apportées par Magento 2, les équipes projets
devront adopter un mode de production « industrialisé ».
•• on peut s’interroger sur les conséquences de la couche service sur le rôle des développeurs
et des intégrateurs et les interactions entre eux au cours des projets.
Sera-t-elle utilisée… ou est-ce que tout passera par l’Object Manager ?
•• de même on peut s’interroger sur l’usage qui sera fait par les intégrateurs de la « UI Library »,
et du découpage des vues au sein des modules
Industrialisation

MAGENTO 2
Ecosystème
•• le suivi et les contributions sont désormais possibles directement via
github.com/magento/magento2 elles peuvent être intégrées et enrichies
•• exemples : dispatch d’événements sur l’envoi de mails,
événement « customer_validate », filtre ip maintenance, …
•• en revanche certaines restent sur la branche develop sans passer
sur la branche master à ce jour (?)
•• des webinaires et une documentation technique
mais qui reste à remettre à jour (2012 > 2014)
•• des exemples de code sont cependant fournis
https://github.com/magento/magento2-samples

MAGENTO 2
Ecosystème
•• le suivi et les contributions sont désormais possibles directement via
github.com/magento/magento2 mais surtout, elles sont intégrées voire
enrichies.
•• exemples : dispatch d’événements sur l’envoi de mails,
événement « customer_validate », filtre ip maintenance, …
•• en revanche certaines restent sur la branche develop sans passer
sur la branche master (?)
•• des webinaires et une documentation technique
mais qui reste à remettre à jour (2012 > 2015)
•• des exemples de code sont fournis
https://github.com/magento/magento2-samples

MAGENTO 2
Roadmap & bilan
1 2 3
Mi-2015
Merchant Beta Enrichissement
fonctionnel 2.x...
Merchant Beta
arrêt des ventes EE 1.x ?
2015 et +Novembre 2015
« 1.x maintenue 3 ans »
Outil de migration disponible, fonctionnel
si conforme aux standards

Tél. 01 45 63 19 89
contact@ecommerce-academy.fr
EXPERTS MAGENTO
Rejoignez-nous
@ecommerce_acdmy
acd.my/blog-eca
acd.my/facebook-eca
Et en vidéo sur :
acd.my/youtube-eca
nos experts vous
présentent leurs
formations Magento
& e-Commerce

Magento 2 à l’essai ! Conférence Bargento 2015 par les experts Magento de l'e-Commerce Academy

Contenu connexe

En vedette (20)

Similaire à Magento 2 à l’essai ! Conférence Bargento 2015 par les experts Magento de l'e-Commerce Academy (20)

Magento 2 à l’essai ! Conférence Bargento 2015 par les experts Magento de l'e-Commerce Academy

Notes de l'éditeur