Conseils, Interviews — 02/09/2013 at 09:42

Vaut-il mieux un framework ou une solution e-commerce ?

by

Un grand dossier de fond, comme on les aime !

Adopter une approche Framework ou une approche Solution est une décision qui va profondément structurer des années de business en ligne pour votre entreprise. Ce sont ici deux philosophies qui, sous l’aspect du détail, se révèlent en fait être un enjeu crucial.

Aujourd’hui, la Squad vous propose un entretien unique, avec trois experts : Christophe Cadic, Directeur du développement chez Darty et Frédéric Plais, CEO de Commerce guys (éditeur de Drupal Commerce) et Philippe Humeau, CEO de NBS System.

Avant d’occuper leurs responsabilités actuelles, deux de ces acteurs ont eu une autre vie, qui va apporter encore plus d’expérience à ce témoignage. Christophe fut le CTO de l’agence Nurun et Frédéric le directeur général de l’agence AF83.

Au-delà d’être respectivement client final et éditeur, ces deux experts ont donc également une large expérience en matière d’intégration.

Je (Philippe) me joins avec plaisir à ce duo pour apporter ma part et soutirer un extrait de cette expérience, à votre destination lecteurs et décideurs e-commerce et nous apporterons aujourd’hui un éclairage sur un point qui pourrait paraître un détail, mais qui en fait est une montagne :

Framework ou Solution pour votre site de E-Commerce ?

 

Framework & Solution : définition

Le framework est une boite à outils. Il fournit des briques essentielles pour réaliser une tache, ainsi souvent qu’une structuration du référentiel de données utilisé (catalogue produit par exemple). Il laisse les développeurs libres de l’adapter à une situation particulière. Un framework est fait pour s’adapter à votre besoin, pour que vous l’utilisiez dans votre contexte et qu’il s’adapte à vos usages et contraintes.

La solution elle est un package qui fait déjà la grande majorité de ce que vous voulez et qui est plus habillé, paramétré et légèrement customisé pour remplir une fonction. Vos processus et votre entreprise doivent rentrer dans le moule de la solution et des portes d’échanges (souvent des webservices) existent pour interfacer cette solution avec les autres composants qui l’entoure.

Les deux présentent des avantages et des défauts, nous allons y revenir mais les deux termes sont parfois utilisés à contre sens ou sans distinction, ce qui peut mener à une confusion.

On peut classer dans les solutions : Magento, Prestashop, Hybris, Websphere, Intershop, ATG, Virtuemart, mais aussi les SaaS comme Demandware. On peut classer dans les frameworks : Drupal Commerce, RBS Change, Spree et Opencart par exemple.

(Vous pouvez d’ailleurs retrouver notre analyse de ces outils dans notre benchmark e-commerce)

La plupart des Java sont en close sources et sont orienté vers l’approche solution, l’approche framework étant, en général, un aspect lié fortement au logiciels opensource et au PHP.

Philosophie de différents acteurs

solution_vs_framework

Echanges & débat avec nos experts

Christophe Cadic : Quel est le fond du débat de cette approche Framework vs Solution ?

En tant qu’ancien intégrateur de solutions web (nda Nurun) passé du coté annonceur (nda Darty), mon point de vue sur la question s’est forgé à travers différents projets aussi bien eCommerce, corporate, institutionnels que communautaires. Chez Nurun, nous avons passé du temps à définir différentes architectures CMS et Ecommerce en php/java/dotnet. 

Dans un projet E-commerce, on part de la liste des fonctionnalités de la plateforme, on coche celles qui nous intéressent, et on voit si ça couvre les attentes. Mais une fois le projet démarré, on est souvent obligé de détricoter ce que fait nativement la plateforme pour en refaire des pans et les spécialiser au besoin. On ajoute donc de nouvelles portions de code à la solution que l’on intègre.

Avec le recul, soit on fait peu de spécifique et ça ne colle pas à l’attente initiale, soit on en fait beaucoup et cela peut complexifier la maintenance et les futures montées de version. C’est un problème de compromis, rien ne collera à 100% [nda : et le client n'aime pas les compromis].

Souvent, on finit par admettre que le framework est plus adapté car il permet de faire du “sur mesure” et offre la possibilité de mieux isoler les briques dont on a besoin. Mieux vaut de bonnes briques simples et abstraites, un mapping de données et d’objets pour binder les datas locales ou distantes, et un moteur de templates très souple, plutôt que d’essayer de tordre une solution non adaptée. Cela permet d’appliquer les design patterns que l’on veut, avec les bonnes persistances, et le tout reste maintenable car rien n’est imposé. Cela offre aussi la possibilité d’implémenter les règles métier et les workflows rapidement. Le seul côté un peu déroutant est que l’on démarre de zéro (sans fonctionnalité existante). Le démarrage est donc plus lent, mais en revanche l’accélération qui suit surpasse l’approche solution.

Fondamentalement, je ne suis pas forcément un fan de PHP (pour des raisons de performance et de permissivité d’écriture), mais il faut reconnaître la richesse fonctionnelle des solutions open source proposées. Attention cependant aux fausses impressions de souplesse et de modularité.”

Frédéric Plais : Le point de vue d’un éditeur de Framework comme Commerce Guys ?

C’est également le point de vue de l’éditeur que je représente.

Chaque site est différent. La grande faiblesse des solutions, c’est qu’elles n’offrent pas assez de possibilités de customisations. Chez les grands comptes, Il y a souvent un business physique derrière qui existe depuis plusieurs dizaines d’années avec son propre système IT,  et des équipes qui ont une première expérience du online et donc une idée très précise de leur besoin. Du coup, cet historique rend souvent les besoins très spécifiques ce qui n’est pas en ligne avec l’approche solution  « out of the box ». 

Dans le concept de Drupal Commerce, c’est l’idée de fond : un noyau robuste, simple et propre, très léger. On ajoute dessus des modules spécifiques de shipping, de checkout, de mise en avant de produit, etc. On peut d’ailleurs le faire avec ou sans interface utilisateur (nda approche webservice). C’est une approche de la customisation, on a un framework puissant, pour manipuler de la donnée facilement.

En complément, avec notre offre “Kickstart”, les ~150 modules à disposition permettent de démarrer avec un système assez complet.”

Christophe Cadic : Quelle est la limite ou l’inconvénient d’un framework par rapport à une solution ?

C’est la quantité de développement spécifique nécessaire qui fait la différence. 

Un Framework est une plateforme intégrée qui permet via un ensemble d’API de développer des fonctionnalités de manière rapide et cadrée. Contrairement à une librairie ou on utilise une fonction ou un autre, le framework fournit des design patterns, des normes d’architecture et de codage.

C’est un cadrage technique structuré qui permet aussi d’industrialiser facilement les tests via du Test Driven Development (classes de test adossées à chaque fonctionnalité et pilotées par un automate au sein d’un processus d’intégration continue). Le framework peut aller jusqu’à être intégré dans l’IDE, c’est un ensemble qui permet de faire du sur mesure. 

Le framework arrive sans fonctionnalité mais avec un potentiel.

La solution arrive avec des fonctionnalités mais moins de flexibilité.

C’est là où Drupal Commerce peut être intéressant avec son approche hybride « solution & framework »“ 

Frédéric Plais : Et vous Frédéric ? La limite ou l’inconvénient d’un framework par rapport à une solution ?

“Le problème de la solution c’est qu’elle se doit de faire des choix et de prendre certains partis pris sur la bonne façon de faire de l’e-commerce. Pour certain client, c’est idéal car cela apporte de la structuration aux clients qui débutent. Mais sur un client mature, c’est différent, on a déjà une éducation et il me parait plus intéressant de coller au besoin plutôt que contraindre.

Dans l’approche Framework, pas de contrainte sur la façon de faire de l’e-commerce, ce qui implique des choix de design plus générique. Du coup, avec une même base de code, on peut couvrir des clients aussi divers en terme de besoin qu’Eurostar ou cartier, voir même créer des marketplaces comme par exemple opensesame.com  sur le secteur de l’ e-learning ou Kollabora.com dans le domaine de l’artisanat.

Le framework permet de modifier le modèle e-commerce, de créer le sien au lieu d’adopter un standard et donc de se démarquer. Battre Amazon en se battant sur ses standards c’est impossible, le framework peut permettre de se différencier, de mettre en place son style de e-commerce.

Christophe Cadic : Dans une grande enseigne, comment cela se passe ?

Le point de vigilance pour un brick & mortar est de composer avec toutes les briques du Système d’Information qui s’est construit mois après mois, année après année.

Tout développement web doit s’interfacer avec la brique CRM développée sur une techno A, avec le circuit de la commande développé sur une techno B, avec le circuit logistique utilisant une techno C, etc … Ces briques ont été développées à des époques différentes et il faut s’adapter à la manière dont elles délivrent et reçoivent les données. Réaliser des évolutions sur la couche web aura des impacts jusqu’à la manière dont les camions vont se remplir pour les livraisons. Il faut donc faire toutes les analyses d’impact et prendre en compte le dialogue entre tous les composants.

L’urgence opérationnelle pilote souvent le développement et c’est normal car nous évoluons dans un monde régi par des lois économiques. On fait donc du développement spécifique pour avoir un résultat rapide et précis, plutôt que de faire un mouvement de fond qui ne répondra pas en temps réel à l’attente. Il faut aller vite pour être compétitif, mais préserver la maintenabilité des dispositifs. Le rapport de force est là.

Faire du “product driven” possède l’avantage de bénéficier de la force de l’éditeur et de faciliter les montées de version, mais cela peut devenir très contraignant si des fonctionnalités à ce titre sont imposées. Le développement spécifique sur solution est efficace mais il nous sort de la ligne de l’éditeur et complexifie la compatibilité ascendante. Ce qu’on gagne d’un côté, on le perd en souplesse de l’autre.

Du coup, dans le contexte d’un brick & mortar, au vu de la diversité des composantes du Système d’Information à interfacer, la solution répond moins bien au besoin qu’un Framework car les dizaines de petits cas particuliers demandent trop de développements spécifiques. L’urgence opérationnelle ne doit pas être freinée par une solution rigide. Même si l’option solution associée à la présence permanente de l’éditeur et de l’intégrateur semble résoudre le problème, c’est un problème de coût qui prend alors le relais.

Frédéric Plais : 

“C’est aussi l’avantage de l’opensource. On ne dépend pas tant que ça de la roadmap de l’éditeur.

Le client final peut construire des briques de façon autonome et sur-mesure et aussi s’appuyer sur la communauté peut assurer la maintenance de certains aspects ou certaines fonctionnalités…”

Christophe Cadic : Et l’opensource pour un grand groupe, c’est envisageable ?

Oui, mais il faut se poser la question de la pérennité et du support.

Quand on est adossé à un éditeur de renom, on sait qu’on ne fera pas d’erreur dans le long terme, mais il faut s’assurer qu’on atteindra le niveau de souplesse et de réactivité nécessaires. Il faut trouver le point d’équilibre.

La maîtrise en interne est une stratégie intéressante, mais elle est plus exposante. En cas de problème nous sommes seuls face à sa résolution. Avec un éditeur et un intégrateur, la pression se répartit plus uniformément.

Frédéric Plais : Les grands éditeurs ont des solutions très spécifiques, pour les grands comptes, comme des OMS (Sterling chez IBM dans le cas présent). Est-ce possible en Opensource d’obtenir de telles briques, trop spécialisées pour être utilisées massivement ?

“L’open source brille sur les marchés de masse plutôt que sur les marchés de niche. 

Cela étant dit, l’open source permet de partir d’un existant et de le transformer à sa guise. En général quand c’est “très pointu et à faible clientèle”, cela revient à faire du sur-mesure quand l’on travaille en Opensource. C’est toujours un atout clé à mon sens car à l’inverse, l’aspect “boite noire” des éditeurs propriétaires peut compliquer la tâche d’interfaçage. Car à l’inverse, si le projet est plus complet en propriétaire, l’Opensource laisse la possibilité de pouvoir s’y interfacer facilement si l’éditeur en a laissé la possibilité par un webservice par exemple.

Sur les sujets à fort volume d’utilisation (logiciels populaires), les contributions enrichissent le logiciel de départ de façon réellement imbattable, Drupal 7, c’est 1 200 contributeurs qui ont au minimum participé à un module ou au core, juste pour le lancement. Cela représente une force de travail absolument imbattable par un éditeur. Donc la communauté Opensource peut faire de grande choses en terme de quantité.”

Christophe Cadic : C’est faisable d’avoir le spécifique sur une fonctionnalité clef comme l’OMS (Order Management System) ou du PIM (Poduct Information Manager) ?

“Avec une petite équipe d’experts triés sur le volet, tout est réalisable.

On travaille en mode Scrum/Agile et c’est très efficace. C’est faisable avec 3 ou 4 personnes mais pas beaucoup plus (la limite à mon avis est autour de 8 maximum).

Avec cette configuration d’équipe, on peut réaliser n’importe quel module spécifique rapidement. On peut même réaliser un applicatif complet en 6 mois. Le risque dans ce cas-là est l’humain car nous sommes sur de l’exploit individuel et cela n’est pas toujours sécurisant pour l’organisation. (nda ceci dit John Carmack a fait les beaux jours d’Id software pendant 20 ans, à lui quasi seul en terme de code du core).

Le mode commando donne donc du résultat, mais il faut fidéliser ces experts et sécuriser l’organisation par un transfert de compétences complet. Dans les grands groupes en général, le transfert de compétence est fondamental en termes de gestion de risque. On doit s’appuyer sur l’organisation du collectif et non pas sur l’exploit individuel.

Frédéric Plais : Il y a une solution ?

“C’est une question de bonnes pratiques.

Pour vous donner un exemple, nous avons travaillé l’année dernière sur un projet qui nécessitait le développement d’un pan entier de fonctionnalités qui n’existaient pas encore autour de Drupal Commerce.

Aussi, très tôt et de concert avec le client, nous avons pris la décision (avec le client) de releaser le code en opensource et de l’intégrer dans la roadmap principale. Le grand bénéfice est que ces développements spécifiques pour le client ont été pensés de façon à répondre à un besoin générique qui est de ce fait maintenu par l’éditeur et de sa communauté Opensource. La part de spécifique à maintenir par le client est donc beaucoup plus faible et l’éditeur a bénéficié d’un nouveau pan de code/fonctionnalité. Au final, l’ensemble est maintenable et tout le monde y a gagné.

(nda : Ce n’est vrai que pour une fonctionnalité qui intéresse d’autres clients potentiels.)

Le modèle Opensource a permis ce résultat en transformant le code spécifique en générique.”

Le meilleur des mondes

Christophe Cadic

Chacune des approches possède ses avantages et ses inconvénients et on ne développe pas de la même manière un dispositif eCommerce pour un brick & mortar établi que pour une startup qui lance son premier site marchand.

Dans le cas d’un développement « sur mesure », ce qui est souvent le cas du brick & mortar établi, un bon compromis pourrait être de combiner de la génération de code avec l’utilisation d’un framework. Rappelons ici que l’utilisation d’un framework impose des design patterns stricts qui ont pour conséquence que le développeur répète des modes opératoires. Or, cela peut s’automatiser avec de la génération de code et donc faire gagner encore plus en productivité. Le framework Symfony est un bon exemple de combinaison « Framework / génération de code », et il peut même être complété par des générations de code spécifiques s’appuyant par exemple sur des transformations Xslt. Cette approche est très compatible également avec les architectures Dotnet et Java.

Pour atteindre cet idéal, il faut déterminer le bon niveau d’abstraction de description des composants (souvent via du XML) pour ensuite générer le code directement sur le framework.

On pourrait donc imaginer un framework eCommerce disposant d’un moteur de panier, d’un moteur de fiche produit, d’un moteur d’espace client, … ces moteurs, vus comme des « potentiels fonctionnels » sans IHM seraient entièrement pilotables par API. Ensuite on décrirait via XML le comportement attendu et une transformation XSLT génèrerait le code qui consomme les API. On peut aller plus loin en imaginant un designer « drag & drop » en amont du fichier descriptif XML permettant à des profils fonctionnels de directement spécifier le comportement et de l’offrir au générateur de code. La philosophie évoquée ici est celle d’un configurateur de dispositif eCommerce, à mi-chemin entre la solution et le framework. 

Conclusion

Quand on est petit et que l’on démarre, l’approche solution (particulièrement SaaS) offre des avantages non négligeables. Elle permet de s’auto structurer en partant sur des bonnes pratiques mises en place par la plupart. La solution couvre les besoins de base et souvent une partie des étendus et elle laisse le nouveau e-commerçant progresser en utilisant petit à petit de plus en plus d’outils déjà présents.

En taille moyenne, c’est un choix plus complexe. Un contact dans le monde B2B de la coiffure me disait un jour “j’ai aussi consulté Hybris car, même si nous sommes obligé de nous conformer à la solution et non pas l’inverse, cela me parait intéressant”. En final, il hésitait entre RBS Change où il avait une approche framework et sur mesures et Hybris où la solution prenait le dessus. C’est donc un réel débat.

La limite est d’ailleurs parfois plus floue car, même lorsque l’on utilise une solution, particulièrement dans le monde des PHP, les clients ont tendance à vouloir un peu de customisation, de sur-mesure, en un mot de spécifique. Cette partie restera un exception par rapport à la base standardisée de la solution et à elle seule, elle devrait amener à songer à l’alternative Framework.

La limite est d’ailleurs parfois plus floue car même quand on utilise une solution, particulièrement dans le monde des PHP, les clients ont tendance à vouloir un peu de customisation, de sur-mesure, en un mot de spécifique. Cette partie restera une exception par rapport à la base standardisée de la solution et à elle seule, elle devrait amener à songer à l’alternative framework.

Si l’entreprise est un pur player Internet, il est peut-être plus facile de se tourner vers l’approche solution car elle couvrira la majeure partie des besoins  sans nécessiter énormément de développement spécifique. Par ailleurs, il devient facile de faire évoluer son applicatif, au rythme des mises à jours de la solution par son éditeur.

Ensuite pour les multi canaux & brick & mortar, le framework permet d’avoir un processus qui va se coupler de la manière la plus optimale possible au besoin du client, à sa logistique, à son organisation, etc.

Les sociétés ayant également un fort existant, une expérience Internet de longue date, ont souvent fait des choix liés à l’histoire de la société, mais des technologies disponibles à la date de ces choix également. Pour ces players, le SI est souvent “fragmenté”, avec des technologies qui ont fait leurs apparitions petit à petit dans l’informatique de l’entreprise. Le framework offre la possibilité d’avoir une colonne vertébrale souple, qui va petit à petit permettre de remplacer les composants vieillissants. Il va aussi affranchir l’entreprise du souci de compatibilité ascendante ou descendante.

En B2B, le choix est très ouvert. Certaines solutions comme Intershop offre une gamme de possibilité quasi parfaite pour couvrir le besoin, tous les cas ou presque sont traités. Souvent, la solution prend le dessus sur le framework car les besoins purement Web sont très similaires mais le framework peut avoir du sens sur le domaine d’activité est si spécifique qu’il faille construire des blocs spécifiques de gestion, de la logistique par exemple.

Pour les très grands, le choix est plus flagrant car, comme le soulignait M. Cadic lors de notre interview, il est difficile de s’affranchir de la politique interne et il faut se reposer sur l’organisation plus que sur l’exploit individuel, sur la maintenabilité, sur l’équipe de l’éditeur. Les biggest, et pur player, comme Vente Privée, font, par exemple, leurs développements sur-mesure, in house.

Mais au-delà de ces cases pré définies, il y a une réelle approche philosophique à avoir : dois-je appliquer les bests practices vue par un autre et adapter mes processus internes (solution) ou dois-je forger le système de E-commerce selon mes besoins et c’est lui qui doit se plier à mes processus (framework) ?

Conseil de la squad : Si vous partez en mode solution, évitez au maximum le développement spécifique, ne touchez jamais au core et en cas de besoin, utilisez les webservices de la solution en question. Faire du spécifique sur une solution, c’est se passer de la force et de la souplesse du framework, sans préserver les avantages du mode solution.

3 Comments

  1. Pingback: les liens de la semaine (weekly) - Les z'ed

  2. Pingback: Vaut-il mieux un framework ou une solution e-co...

  3. Pingback: Vaut-il mieux un framework ou une solution e-co...

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>