Historique

Il est important de mettre en perspective l'évolution des outils e-commerce web. Avant Magento, les développements  web étaient dominés par Oscommerce. Os commerce a été créé en 2000 écrit en PHP/mysql sous licence GPL. A partir de la version 3 en 2005, OS Commerce n'a plus significativement évolué.
Magento a été lancé en 2008 par la société Varien. Depuis 2010, Magento existe en 3 versions, une version dite "communautaire" gratuite et open-source, une version "professionnel" et une version "entreprise".

Le bon technologique entre les 2 outils est considérable.
Dans Os commerce, la présentation est sous forme de 3 colonnes ... et c'est en dur dans le code. Il n'y a pas de mécanisme de template. On peut juste agir sur la CSS et les images pour habiller. Des bibliothèques de templates existent mais l'installation d'un template suppose la réinstallation d'une instance complète d'Oscommerce.
Oscommerce est également très monolithique. Il a été écrit sans programmation objet ( et en PHP4 vu que le PHP5 et la vrai POO ne sont arrivés qu'en 2004). Et pendant longtemps, il n'y avait pas vraiment d'alternative crédible à Oscommerce. Il n'existe pas de statistique mais il est possible que OSCommerce soit encore la boutique la plus répandue sur le web.

Magento est arrivé avec une vrai programmation objet, système de template, système de modules, multi-pays, multi-boutique, multi-monnaie, etc ...sur un marché écœuré par les limitations d'Oscommerce. Le succès a été immédiat. Le projet est récompensé "meilleur nouveau projet Open Source" par Sourceforge en 2008.

Vers des projets plus ambitieux

Magento permet d'aller loin et se suffit à lui même dans beaucoup de situation. Par ailleurs, Magento est basé sur le framework Zend et il est donc facile de compléter ou modifier (en surchargeant le modèle objet) les fonctionnalités de Magento pour répondre aux besoins d'un client. De même, le modèle de données est très malléable. Magento est donc un outil extrêmement flexible.

Si osCommerce a bien été utilisé par des grandes entreprises, il ne l'était généralement qu’accompagné d'autres outils. Par exemple le couple Typo3 + OsCommerce a été assez courant (Typo3 a été présenté sur ce blog dans ce billet). Typo3 prenait en charge toute la partie marketing home, rubrique, fiche produit et OScommerce n'intervenait que pour le tunnel de commande.

Magento remplace ces architectures multi-CMS et ouvre les possibilités de fonctionnalités métiers particulières non-limité à la boutique en ligne classique. Tous les projets ne sont pas des petites boutiques dont le travail se limitent à l'intégration d'une charte graphique sur mesure. Beaucoup de projet vont inclure à Magento des spécificités liées au métier du client et induire des modifications importantes dans le comportement, dans les fonctionnalités voir même vont nécessiter la création de fonctionnalités complètement nouvelles et spécifiques.
Bref, beaucoup de liberté... trop ?

Flexibilité et complexité

Avec Magento, tout est possible. Mais cette flexibilité (ou plutôt cette capacité à la flexibilité) a un coût.
Pour être flexible, le modèle de données est organisé via une surcouche. Une table stocke la liste des champs personnalisé et leurs formats. De cette manière la création d'un attribut à un produit ne nécessite pas un droit d'écriture en base. C'est flexible. Par contre, l'affichage des caractéristiques d'un produit va générer l’exécution de requête avec de nombreuses jointures. Varien a donc optimisé le problème avec une couche supplémentaire "le catalogue à plat". Toutefois, ce modèle devrait être abandonné dans la prochaine version majeure de Magento.
Les modifications du modèle de données sont possibles par le développeur via des updateurs. Magento inclus un mécanisme de version de modèle et qui lors de son déploiement sur une nouvelle instance va rejouer les différentes modifications. Ce code reste embarqué dans l'application. La démarche de gestion structurée de la base de données est inattaquable mais est-ce vraiment à Magento et à du code php de gérer ça ?
Magento embraque des fonctionnalités de CMS, mais rien de comparable à un outil dédié comme Typo3.

Du côté du PHP, la complexité est identique. Un jour, j'ai généré la trace (le recueil de tous les appels de fonctions pour une requête) d'une exécution Magento en utilisant xdebug et Kcachegrind.
Cela donne le schéma suivant. Chaque rectangle est un appel de fonction. La taille est proportionnelle au temps d’exécution. (il y a un problème dans l'envoi de mail / le gros carré rouge, mais ce n'est pas le sujet).


Bref, ... des milliers d'appels. C'est certainement très générique avec plusieurs de couches d'abstraction (les classes Zend, puis les classes Varien, les classes Magento et enfin les classes du projet développé), mais pour afficher une page de confirmation de commande (== générer un fichier html, on fait du web quand même). Est-ce utile ?
A l'inverse, on peut se demander où est la gène pour une boutique en ligne d'un site quelconque. Si le trafic n'est pas important, la charge ne sera pas un problème (ou pas tout de suite)
A terme, l'architecture logicielle vient gommer les manifestations du problème en ayant recours à des caches mais certaines pages non-cachables resteront lourdes.

Le client est roi

Magento a du succès chez les grands comptes pour les projets e-commerce aboutis pour plusieurs raisons:
- il y a une vraie entreprise derrière, un support, une documentation
- c'est un produit pret à l'emploi. On l'installe et "pouf" on a une boutique.
- maintenant c'est très répandu, un classique.
A priori, cela défend bien le choix de l'outil. Toutefois, on rencontre beaucoup de clients un peu déçus par la réalité des faits. Car faire faire du spécifique même sur un framework très évolué, c'est du développement. Un développement qui hérite des contraintes de toutes les couches. On se retrouve dans des déceptions dans :
–    les délais, avec des lancements repoussés (ou un périmètre réduit)
–    la qualité, les performances, la tenu en charge
–    le coût..

Souvent, on a "oublié" d'étudier la possibilité d'un développement spécifique pour répondre au besoin du client. Il me semble que dans des projets contenant un volume  de besoins spécifiques plus important que le volume des fonctionnalités utilisées dans Magento, il faut se poser la question. Et ouvrir les éventualités suivantes:
–    gérer l'évolution du modèle de données par un outil externe plutôt que via les updateurs Magento (exemple: Mysql Workbench ou NeXtep).
–    un CMS tiers puissant (genre Typo3 ou Drupal)
–    évacuer les problèmes de performance
–    évacuer des problèmes de cache spécifique à Magento
–    un temps de développement non ralenti par la méconnaissance d'un outil dont la documentation est introuvable sur le web
–    du temps et une énergie disponible pour de la conception, de la factorisation, du test unitaire. L'outil ne fait pas tout...
–    l'interface d'admin n'est pas forcément réutilisée (et elle est solidaire de l'application) on ne peut pas la retirer d'un serveur front. Ca peut poser problème à certain client.
–    recoder complètement un tunnel de vente

Pour mon projet, Magento c'est bien ?

• Oui, pour tous les sites de ventes de produits avec un business model "classique". Avec un thème sur mesure, on a rapidement une boutique avec beaucoup de fonctionnalités pour un effort limité.
• Oui, pour les boutiques avec quelques spécificité car la généricité est intéressante et va permettre de bâtir un site en bénéficiant des extensions déjà disponibles.
• Non, pour réinventer le e-commerce... réaliser le comportement spécifique recherché; pour une boutique qui ne suit pas un modèle classique de tunnel; un type produit inhabituel; une gestion des stocks particulière... bref une boutique qui implémente un métier différent de la simple vente, différent des racines de Magento. Dans ces cas, la généricité est une grosse contrainte.

Conclusion

Les produits sur étagères sont à la mode. Il faut comprendre qu'il est plus facile pour un décideur de (se) défendre un projet basé sur une solution très répandue (et avec le support d'un éditeur) plutôt qu'un projet de développement sur-mesure qui part de rien. Il est également confortable de penser que les mécanismes (lourd) du framework sous-jacent vont encadrer les développements

L'envers du décor, c'est la nécessité de tordre les outils pour arriver à répondre au besoin pour finalement subir autant si ce n'est plsu de problème et de risque qu'un développement traditionnel.

Beaucoup de projet semble suivre le même travers. Toute la généricité et l'adaptabilité sont portés dans le code source déployé sur le serveur de production. C'est inutile ! Il serait plus cohérent qu'une étape intermédiaire entre le développement et la mise en production transforme le code pour en faire un code optimisé (et plus générique).

Si le progrès technique a permis de se débarrasser d’os-commerce, au delà de Magento, c'est l’intérêt de l'usage systématique des framework lourds (Zend, Symfony) qu'il faut peser.