Du produit à sa commercialisation en ligne … et au-delà ! (Première partie)

(Remarque : le présent article est initialement paru en deux parties, dans le magazine Programmez n°211 (octobre 2017) et n° 212 (novembre 2017). En voici la première partie et retrouvez la seconde partie ici).

La conception d’un site e-commerce ne peut pas se résumer à une simple opération technique. Un ensemble de sujets tant métiers que techniques sont à considérer, avant sa mise en ligne. Une fois le site ouvert aux utilisateurs, il convient de l’exploiter, de le faire vivre et le maintenir. Ce dossier développe les aspects théoriques liés à la mise en œuvre d’un site e-commerce, ainsi qu’un exemple de site basé sur le développement d’un instrument de musique MIDI réalisé il y a quelque temps : la tirasse MIDI.


Le logiciel de tirasse en action sur un raspberry Pi
Pour les curieux ou celles et ceux que cela intéresse, découvrez plus en détail la réalisation de la tirasse à l’adresse https://www.sodifrance.fr/blog/tirasse-midi-du-besoin-a-la-realisation/

1.1 Etapes préalables à la conception du site : identifier son marché et sa cible de clients

Préparons notre plan de conquête du … marché

Il faut conserver à l’esprit qu’un site e-commerce est un “outil” et non une fin en soi. Son objectif premier est de permettre à une marque d’offrir à ses clients une expérience d’achat unique et singulière qui parfois s’inscrit en complément d’espaces physiques existants (magasins). Mais ce n’est pas tout, ce nouveau canal de vente doit aussi répondre à des attentes économiques notamment en termes d’activité de vente et de profits. Ainsi, un site e-commerce est un canal de vente à part entière mais non exclusif. Des places de marché, comme Amazon Marketplace, ou Ebay sont également d’autres supports envisageables.

Trop d’entreprises se contentent d’un site “vitrine” de présentation de leurs produits et déportent la vente sur un autre canal (échange de mails puis un paiement par virement par exemple). Cette présence limitée si elle permet une présence en ligne en offrant un premier niveau de services n’est toutefois pas totalement satisfaisante.


// Et pour la tirasse …
En quelques mots, la tirasse MIDI est à la base un dispositif logiciel qui reçoit en entrée un signal MIDI (note de musique, durée, volume, …) en provenance d’un instrument et qui transmet en sortie un signal MIDI à destination d’autres instruments également. La tirasse est donc une solution logicielle, qui lie à la fois musique et informatique. Nous allons dans notre exemple commercialiser cette solution sur un site e-commerce.

La création d’un site e-commerce naît d’une réflexion souvent portée par une direction métier (commerce, marketing) qui doit avant de se lancer apporter des réponses à des éléments structurants et essentiels : nom du service (marque), typologie des clients, nature de la concurrence directe et indirecte, objectifs de ventes, moyens de promotion et de communication, politique de prix, stratégie d’animation commerciale, analyse des flux comptables et logistiques, stratégie de sourcing … Ces éléments sont souvent formalisés dans un business plan qui pourra s’appuyer sur des analyses stratégiques de type PESTEL ou Porter par exemple.


// Et pour la tirasse …
Dans le cadre du futur site e-commerce destiné à commercialiser la tirasse MIDI, nous avons identifié un marché de niche : les organistes (disposant d’une installation modulaire).
Ce cœur de cible peut être élargi aux revendeurs d’instruments, les écoles de musique et éventuellement les chorales.
Le site devra donc répondre aux besoins de ces différentes typologies de clients. Le produit sera une solution sous licence libre, mais des frais de distribution pourront être demandés, sous la forme d’une promesse de don à faire à une oeuvre caritative laissée au choix du client.
Dans notre exemple, les flux sont plutôt limités :

  • Pas de flux logistique (logiciel délivré en ligne à la fin de la transaction),
  • Pas de flux comptable (pas d’interfaçage avec un ERP ou un back office de gestion),
  • En revanche existence de flux commerciaux via une base de données Client ou une solution tierce de type CRM (disponibilité de nouvelle version, services proposés, produits connexes (cross sell)).

La charte graphique est celle par défaut de Magento.

Il est important avant de l’ouverture d’un site e-commerce de ne pas omettre certains aspects légaux par exemple :

    • Les conditions générales de vente,
    • Les conditions générales d’utilisation du site,
    • Les propriétés spécifiques du site (identité de l’éditeur, hébergeur …)
    • Les informations relatives au traitement automatisé des données nominatives (obligations relatives à la CNIL, cookies, publicité, …)

1.2 Les prérequis techniques

Pas de bons résultat sans de bons outils et une préparation minutieuse. Alors préparons-nous précautionneusement !

Les prérequis techniques sont en général ceux exigés par les sites internets, complétés par les prérequis des systèmes utilisant des bases de données de manière assez intensive. À cela s’ajoute souvent dans les sites e-commerces des composants quasi obligatoires tels que des serveurs de cache. Mais passons en revue les principaux prérequis :

      • Un nom de domaine : bien qu’un site pourrait, du point de vue technique, tout à fait utiliser un nom de machine fourni par l’hébergeur, les clients doivent pouvoir identifier simplement l’entreprise : un nom de domaine ainsi qu’une résolution de nom correspondante est donc indispensable. Une précaution pour l’avenir sera néanmoins de vérifier si le registrar sera en capacité de supporter les extensions liées à IPv6 et celles liées à DNSSEC.// Et pour la tirasse …
        Pour les besoins de l’article le domaine sera tirasseorgueelectroniqueliturgique.fr. Une recherche rapide effectuée auprès d’un registrar indique que ce nom est disponible. Pour le développement local, tirasse.local sera employé.
      • Une messagerie électronique : a minima, il convient de disposer de redirections vers des adresses électroniques tierces, mais pour capitaliser sur la marque, il est plus pertinent d’avoir un service de messagerie pour le domaine fournissant des services à accès sécurisés (imaps pour la réception, SMTP STARTTLS ou SMTPS pour l’envoi et bien entendu HTTPS pour le webmail)// Et pour la tirasse …
        Au niveau de la messagerie électronique, nous choisissons d’avoir au moins deux adresses : une adresse de contact et une adresse pour la boutique.
      • Une plate-forme e-commerce contraint par ses propres pré-requis techniques. Ce choix doit être fait avec minutie, il est en général délicat a posteriori de passer d’un système à un autre.// Et pour la tirasse …
        Dans le cadre de cet article, nous utiliserons la solution open source (leader) Magento. 
      • Un serveur HTTP (avec sa bande passante) : il servira à fournir la plupart des éléments relatifs au site e-commerce. En fonction de l’importance du site, il peut être utile de le doubler (un serveur de front-office et un autre de back-office). Plusieurs noms pourront éventuellement être servis de sorte à accroître le nombre de connexions en parallèles d’un navigateur pour récupérer le site plus rapidement.
        // Et pour la tirasse …
        Le site étant modeste, nous choisissons un seul serveur web dédié situé dans un réseau interne hébergé, sur lequel plusieurs serveurs physiques sont possibles. En terme serveur HTTP, le choix se fait entre Nginx et Apache HTTPD, nous retiendrons pour notre part ce dernier.
      • Un ou plusieurs certificats HTTPS : jusqu’il y a peu, on considérait que seules certaines sections critiques se devaient d’être accédées via HTTPS, comme les informations clients mais aujourd’hui, la fourniture d’un service d’accès totalement en HTTPS devient la norme. Trois choix s’offrent à nous :
          • un seul certificat avec un nom unique
          • un seul certificat avec un nom générique (un certificat wildcard)
          • un certificat par nom desservi.

        En cas de fort trafic, il arrive que des proxys SSL frontaux soient mis en place pour chiffrer les communications avec les utilisateurs finaux, de sorte à délester les serveurs métiers.

        // Et pour la tirasse …
        Le site étant initialement modeste, nous utiliserons un certificat wildcard de sorte à pouvoir bénéficier des effets de multiplexages dus à l’utilisation de plusieurs noms. Compte tenu du nombre de serveurs HTTP, c’est une décision fonctionnelle. Néanmoins, si le site se développe, il faudra s’orienter vers des certificats non wildcard (chaque instance disposera d’une clef privée propre).

      • Le serveur de base de données : il est la clef de voûte de toute plateforme e-commerce. C’est lui qui stocke une bonne partie des informations sur les produits, clients, devis et commandes. Il est donc critique dans l’architecture de la solution. Hautement sollicité, c’est un système qui doit être performant sous l’angle matériel (disques durs, contrôleurs de disque dur, bus, mémoire vive) mais aussi vis-à-vis de l'administration logicielle (dimensionnement de l’instance du serveur de base de données pour ne citer qu’elle). Une particularité de la base de données dans un site e-commerce est que cette dernière n’est pas figée, elle “vit”, dans la mesure où à tout moment des actions utilisateurs peuvent engendrer des créations/modifications de données.// Et pour la tirasse …
        Le serveur de base de données choisi est MySQL, SGBD traditionnellement utilisé avec Magento. Pour l’hébergement de la base de données, nous souhaitons que celle-ci soit hébergée sur des SSD redondés (via du RAID 10). Nous souhaitons une sauvegarde complète chaque nuit, associée à une sauvegarde des logs de la base de données. Nous acceptons de perdre jusqu’à une journée de commandes, sachant que nous allons configurer Magento pour nous envoyer une copie de mail pour chaque création de compte ou commande passée. Ainsi, nous pourrons quand même disposer des informations nécessaires pour recréer au besoin les clients et les commandes en se basant sur les mails.
      • Le mécanisme de stockage du cache : dans un site e-commerce, il est important que les temps de réponse soient rapides même lors de la consultation par un grand nombre de clients simultanément. Or, générer une page complète peut prendre du temps. C’est là que les caches entrent en jeu : ils permettent de ré-exploiter des entités qui ont déjà été calculées et supposées être encore valides pour l’usage qu’on souhaite en faire (techniquement, on calcule une clé de stockage dans le cache, le résultat peut être réutilisé si cette clef est présente et l’entrée n’est pas trop vieille). On trouve des caches pour un certain nombre d’éléments, tels que la gestion de la configuration ou la génération de blocs HTML dans la page. L'inconvénient est qu’il est nécessaire de disposer de clés de cache suffisamment précises pour tenir compte des différents éléments conditionnant l’affichage et qu’il faut parfois changer le type de programmation (usuellement remplacer de la programmation serveur PHP par de la programmation Ajax au niveau du navigateur) pour optimiser l’utilisation du cache. Il faut également stocker le résultat, dans un stockage rapide.// Et pour la tirasse …
        Magento propose plusieurs types de stockage, dont le stockage du cache dans un serveur Redis. Le serveur Redis a comme gros avantages sa rapidité et sa sauvegarde de données dans un fichier, ce qui permet de ne pas “forcément” partir d’une situation de cache froid lors d’un redémarrage (en contexte de déploiement, l’habitude est de vider les caches).
      • Le mécanisme de stockage des sessions : le maintien des sessions est, comme vu précédemment, essentiel au bon fonctionnement d’un site e-commerce. Il s’agit non seulement de stocker la liaison avec le cookie de session transmis au navigateur pour retrouver les éléments liés dans la base de données, mais également stocker les données d’état volatiles et qui doivent être accessibles rapidement, par exemple la protection de formulaires avec des clefs.
        À nouveau, Magento propose plusieurs types de stockage, dont du stockage Redis. À ce niveau, nous pouvons comprendre que le stockage sur disque dur présente un intérêt, de sorte qu’un client notamment ne perde pas ses données de panier lorsqu’il n’est pas logué et que le serveur de cache de sessions est redémarré. Néanmoins étant donné la volatilité des données et le fait que l’on peut souhaiter en cas de problème repartir sur des bases saines et une situation “stable”, nous prenons le parti de dire que perdre les données de session est un moindre mal et qu’il n’est pas nécessaire de les stocker. Un serveur Memcached peut également faire l’affaire dans notre exemple, car les produits proposés sur le site ne seront pas très variés, donc il est rapide et simple pour un utilisateur de refaire son panier si nécessaire. À noter qu’en multi-instance (plusieurs serveurs Magento faisant tourner le même FO par exemple), il devient primordial d’avoir un mécanisme de sessions centralisé, pour que le traitement sur différents frontends successifs conduise à une expérience homogène pour l’utilisateur.
      • le serveur de cache full page cache en frontend : ce genre de serveur est un serveur qui peut remplacer un full page cache intégré à Magento : se positionnant devant les serveurs frontend, il récupère d’abord les requêtes et ne les transmet au serveur frontend que s’il ne peut pas y répondre lui-même. Ce type de serveur se trouve surtout dans les installations où il n’y a pas de full page cache, ou en frontal d’instances extrêmement sollicitées. La programmation des pages est impactée par ce type de serveur. De plus sa configuration n’est pas anodine. Un exemple connu de serveur de cache est Varnish.Pour les curieux : mettre en place du Varnish n’est pas toujours évident et peut demander des efforts de débuggage : https://www.sodifrance.fr/blog/retour-dexperience-sur-un-debuggage-varnish/Comme le site de la tirasse ne sera vraisemblablement pas grandement sollicité, la mise en place d’un full page cache en frontend serait disproportionnée. Pour qu’un cache se justifie, il faut que ce cache soit réellement utilisé pour servir des pages : avec un trafic moindre, il est probable que des délais de validité extrêmement longs soient nécessaires à son utilisation.
      • le service de recherche : généralement, sur les grands sites de vente, la quantité d’articles disponibles est telle qu’il est plus efficace d’utiliser les moteurs de recherche intégrés pour trouver le produit désiré. Cependant, la réalisation d’un système de recherche présente quelques difficultés : il faut savoir dans quel contenant chercher (pages de produits, pages de catégories, pages CMS, …) et tenir compte des documents pour les indexer au mieux.
        En ce qui concerne la tirasse, l’intérêt de pouvoir faire des recherches ne réside pas tant sur le fait de rendre disponible un produit que de pouvoir chercher à fournir à l’utilisateur la réponse à son besoin sous la forme d’un aspect produit auquel il sera sensible (sous diverses formes : textes, images, voire du son et des vidéos). Ces derniers types de documents sont certes difficilement indexables en eux-mêmes, mais il est toujours possible de chercher à renseigner leurs métadonnées pour les rendre présentables par un moteur de recherche. De plus, il est important de disposer d’outils puissants d’analyse des requêtes utilisateurs. Dans le cadre d’une évolution future, nous partirions donc plutôt pour un serveur SOLR dédié, avec une configuration et une interface d’utilisation adaptées au besoin, donc personnalisées.
      • Les outils d’analyse de trafic : ils sont importants, car ils permettent de suivre la fréquentation du site et d’en savoir plus sur les réactions des utilisateurs afin de pouvoir l’optimiser. Ces outils peuvent se situer aussi bien au niveau du serveur (logs Apache HTTPD par exemple) qu’au niveau client (l’un des outils les plus connus étant Universal Analytics). Cependant, comme ces outils doivent pouvoir être, dans une certaine mesure, déployables par des non techniciens, de plus en plus de gestionnaire de balises sont utilisés pour les intégrer, ces derniers permettant d’avoir une plus grande souplesse par rapport à des procédures de déploiement souvent longues à mettre en place.
        Même dans le cadre d’un site modeste il peut être intéressant de disposer d’outils de ce genre : une utilisation standard de GTM et de UA permettront d’obtenir d’emblée des informations avec peu d’efforts. L’effort de personnalisation (qui consiste souvent d’abord en l’enrichissement du DataLayer, puis en l’enrichissement des tags) pourra être réalisé lors d’une évolution du site.
      • Les outils d’analyse de performance : ils permettent de tester la rapidité de réponse des pages et proposent généralement des axes d’amélioration. Ils peuvent également avoir un impact sur l’appréciation des moteurs de recherche, en vérifiant, par exemple, que les moteurs de recherche réussiront à analyser les documents produits. Dans cette rubrique, on pourra donc utiliser des éléments comme les Google Web Tools, PageSpeed, ou Gtmetrix.
        Il est important de tenir compte de ce genre d’outils qui cherchent à améliorer le confort des utilisateurs, d’autant que ce confort est également une qualité qui pourrait éventuellement être prise en compte dans le classement de résultats sur une recherche.
      • Le Content Delivery Network : si on souhaite proposer des contenus “gros consommateurs” en bande passante, il devient intéressant d’utiliser un réseau de distribution de contenu qui est spécialisé dans ce genre de besoins, afin de préserver les ressources pour le véritable site boutique. Certains CDN font maintenant même parti de la “vie courante”’, comme Youtube ou Cloudfront.
        Etant donné que le site de la tirasse devra fournir des vidéos pour la montrer en configuration et en action, le CDN sera requis dans le cadre de ce projet.
      • Les transporteurs (flux de livraison) : généralement plusieurs situations d’enlèvement et de livraison de colis spécifiques sont considérées :
        • pas de livraison du tout, notamment lorsque le produit est numérique, ou que le client se déplace sur le site physique,
        • dépôt à un centre d’envoi ou récupération dans un point colis correspondant,
        • enlèvement chez le fournisseur ou réception à domicile.

        En outre, il faut surtout veiller qu’il existe un, voire deux moyens de livraisons pour tout produit vendu sur le site et toute adresse de livraison acceptée. En fonction des conditions contractuelles avec les transporteurs, il arrive que la mise en place de la gestion des frais de livraison soit plus ou moins simple à intégrer, allant de frais fixes jusqu’à l’appel de web services tiers.


        Dans le cadre de la tirasse, le produit étant logiciel, nous compterons sur les mécanismes natifs de magento pour assurer la livraison sous forme de téléchargement.

      • Les moyens de paiement : il y a de nombreux prestataires et méthodes de paiement disponibles ; cependant, on peut segmenter les moyens de paiement globalement en quatre catégories :
        • Les paiements hors ligne :
          Ces paiements se font de manière non électronique : typiquement, il s’agit de paiements en espèce ou en chèque, ou de virements qui sont effectués hors site. Après réception du paiement, le paiement doit être validé manuellement dans le logiciel e-commerce depuis le back-office,
        • Les paiements internes au site :
          C’est le cas des cartes cadeaux, des avoirs, voire des coupons de réduction, qui sont des flux enregistrés dans le site, utilisés pour réduire le montant à payer, éventuellement jusqu’à obtenir une commande gratuite,
        • Les paiements par carte (et les paiements de type Paypal) :
          Le plus généralement, le système prépare les paramètres nécessaires pour rediriger le client sur le site de paiement avec lequel le commerçant a un contrat. Dans ces paramètres, sont mentionnés le client, le commerçant, le montant, ainsi qu’une signature des paramètres qui est réalisée grâce à un secret partagé avec le système de paiement. Le client passe alors de manière directe ou indirecte (iframe) sur le site de paiement et saisit ses identifiants de carte bancaire. De là, il y a une demande d’autorisation et éventuellement une demande de capture du montant qui est demandée. Si la demande de capture n’est pas produite en même temps, elle peut être émise ultérieurement, par exemple par un traitement récurrent automatisé. Le résultat du traitement est passé du site de paiement au site e-commerce via un appel direct appelé généralement IPN (Instant Payment Notification) et le client est ensuite redirigé sur le site du commerçant, sur une URL dépendant généralement du résultat (URL de succès, URL d’échec, URL d’annulation, si le client n’a pas cherché à payer). Il est à noter qu’avec la différence entre autorisation et capture, on peut parfois demander une autorisation pour un certain montant et faire ensuite des captures successives jusqu’à concurrence du montant autorisé : cela peut par exemple être utilisé dans le cadre d’une commande envoyée en plusieurs fois, où le commerçant débite les articles uniquement lors de l’envoi.
        • Les paiements par prélèvement SEPA :
          depuis son avènement, le système SEPA simplifie les paiements électroniques. Concrètement : le vendeur établit un Mandat SEPA, avec un certain formalisme (présence de mentions obligatoires). Le client le signe et le vendeur le conserve. Le vendeur pourra ensuite demander via son prestataire de paiement des ordres de prélèvement et ce, en accord avec le mandat qui a été signé et uniquement après information préalable du client. En ce qui concerne la signature du mandat SEPA, elle peut se faire soit manuellement (signature papier) soit électroniquement (et plutôt numériquement, via des certificats). La démarche de signature électronique est d’ailleurs facilitée par une pratique assez récente appelée le “cloud signing” : un tiers s’occupe d’identifier la partie qui doit signer un document, génère un certificat pour le signataire et le signe lui-même pour le compte du signataire (avec son accord) après s’être assuré de son identité et de sa volonté de signer. De la sorte, l’usage de la signature électronique peut simplifier les démarches. Avec la signature du mandat SEPA qui est obligatoire, on peut également chercher à ajouter le contrat de vente aux documents à signer. Néanmoins, il faut faire attention à ce que le tiers s’occupant de la signature électronique soit bien reconnu, comme prestataire de services de confiance qualifié, par les autorités, de sorte que la signature électronique dispose de sa valeur juridique. Il arrive que des prestataires de paiement fournissent aussi des possibilités de signature électronique. Le SEPA a un intérêt surtout dans le cas des paiements récurrents (par exemple, des paiements d’un abonnement).


        Dans le cadre de la tirasse, un nouveau mode de paiement sera implémenté : la promesse de don. L’idée est de donner une somme indicative au niveau des produits, somme reversée aux associations. Dans ce cas, le produit “commercialisé” sur le site n’est pas la tirasse en elle-même, mais la fourniture de la tirasse.

      • La supervision et la maintenance sont deux domaines qu’il ne faut en aucun cas négliger. En termes de supervision, il y a tout d’abord la surveillance des différents serveurs qui ont été cités jusqu’à présent : il s’agit donc de surveillances système et applicatives pour lesquelles il existe de nombreux outils, tels que Nagios et ses différents plugins. Cependant, il est envisageable de mettre en place une surveillance spécifique à Magento, comme vérifier si les tâches de maintenance dans le cron Magento se planifient et s’exécutent bien. Ou encore il est envisageable, après un certain temps de fonctionnement du site, de définir des paramètres minimums de fonctionnement (par exemple sur l'accroissement du nombre de paniers ou de commandes), ou chercher à détecter des problèmes dans les flux de commandes (par exemple, monitorer le flux des commandes pour contrôler la bonne arrivée des IPN). D’autre part, en ce qui concerne la maintenance, il y a lieu de prévoir dans la mise en place du site la possibilité de mettre le site en mode “maintenance”, c’est-à-dire un mode qui permettra un accès restreint pour des déploiements, notamment, qui permettra de ne laisser arriver sur la partie “e-commerce” du site que certaines IP autorisées. Il convient également de se familiariser avec des outils en ligne de commande de Magento, tel que les shells Magento et ne pas hésiter à se développer des shells répondant aux besoins métiers spécifiques. Enfin, il faut souligner que certains outils, comme n98-magerun (https://github.com/netz98/n98-magerun) sont particulièrement utiles, qu’il s’agisse de vérifier les planifications, de lancer une tâche cron manuellement, ou de lancer des morceaux de code particuliers.

        Exemple d’utilisation de magerun
        Pour les curieux : une autre possibilité explorée : interfacer Magento avec du SNMP, ce qui est une manière d’intégrer la supervision d’un applicatif avec des outils systèmes (https://www.sodifrance.fr/blog/integration-magento-et-snmp/).
      • La sauvegarde : il est connu que cette dernière est un élément clef de tout système d’information. À travers la liste des composants énumérés ci-dessus, nous avons déjà une bonne idée de ce qu’il faut absolument sauvegarder et des pertes permises (données volatiles ou reconstructibles). Il est évident qu’il faut sauvegarder la base de données puisque c’est le coeur du système. De plus, il ne faut pas oublier qu’en cours d’utilisation normale, des fichiers peuvent être importés sur l’instance, notamment des images. Ainsi, il faudra aussi penser à sauvegarder le répertoire /media, sachant que ce répertoire peut devenir assez volumineux. En ce qui concerne les fichiers liés à Magento même, il peut toujours être arrangeant de disposer des fichiers sous forme de sauvegarde, mais il faut également pouvoir être en mesure de réinstaller les fichiers en se basant par exemple sur les sources stockées dans un dépôt Git, notamment en cas de suspicion de compromission. Dans le même esprit, on gardera en particulier un exemplaire de fichiers importants de configuration, comme app/etc/local.xml, ou app/etc/applied.patches.list . Pour l’indexation et le cache, le mieux est de pouvoir les régénérer si nécessaire.
        Il faut bien garder à l’esprit qu’une sauvegarde n’est utile que si elle peut être restaurée : il convient donc de vérifier l’utilisabilité des sauvegardes et la mise à jour des procédures qui en découlent en fonction de la vie du système. Un bon exercice de restauration est la mise à jour des environnements de pré-production et de recette, par exemple.
      • Les différents environnements requis : il est bien entendu nécessaire de disposer d’un environnement de production, mais ce n’est pas le seul. Il faut au moins disposer aussi d’un environnement de préproduction, ressemblant le plus possible à la production. De même il faut disposer d’un environnement d’intégration pour lancer les tests unitaires et d’un environnement de développement (ce dernier étant le plus souvent présent sur les postes des développeurs). Le fait d’avoir ces différents environnements permet de pouvoir s’assurer le plus possible que les modifications apportées ne porteront pas préjudice à la production.
        Dans le cadre de la tirasse, comme le projet restera petit, il est envisageable de mettre la production et la pré-production sur les mêmes machines. Néanmoins, pour des projets plus vastes, il convient de bien séparer et isoler les environnements, car il ne faut pas que des problèmes comme une surconsommation de ressources en pré-production n’affecte la production.

On a maintenant une longue liste des prérequis techniques. Voyons brièvement comment nous pouvons les situer dans un exemple de schéma conceptuel simplifié d’infrastructure :


Exemple de schéma conceptuel d’infrastructure

Le schéma divise l’infrastructure en quatre parties :

      • L’infrastructure client, nécessaire au client pour accéder au site,
      • L’infrastructure tierce de services : fournisseurs de services apportant des fonctionnalités au site par divers moyens techniques,
      • Le système d’information métier : coeur du système d’information de l’entreprise
      • L’infrastructure du site : infrastructure dédiée au site.

Comme les serveurs et sites webs sont des cibles communes d’attaques, il convient d’isoler le site web pour limiter les éventuels dégâts : d’où des routeurs firewall (pour simplifier, car ils pourraient aussi assurer des fonctionnalités plus avancées comme de l’inspection de trafic ou du proxy applicatif, voire de l’offloading SSL) à plusieurs niveaux. Etant donné qu’il y a beaucoup de trafic en mode anonyme (client non loggué) avec des pages récurrentes, on peut penser mettre un cache HTTP en front et ne laisser arriver au serveur Magento que du trafic qui est passé par lui (contrôles supplémentaires possibles). Au niveau du coeur de l’infrastructure du site Magento, nous avons uniquement représenté les éléments les plus fréquents à savoir le serveur web, le serveur de BD, le stockage du cache et le stockage des sessions - ce qui n’exclut pas les autres outils présentés auparavant. En revanche, nous pouvons nous poser la question s’il convient de laisser les machines dans la même zone de sécurité, ou s’il ne faudrait pas plutôt chercher à contrôler le trafic entre les machines … Mais aucune des deux approches n’est parfaite.

Il est à remarquer que deux liaisons distinctes sont représentées pour la connexion à Internet entre l’infrastructure métier et l’infrastructure site web : les caractéristiques de trafic ne sont pas les mêmes et l’hébergement du site peut par exemple être déporté sur un cloud. Néanmoins, il pourrait être intéressant d’avoir une liaison privilégiée entre les deux infrastructures, en particulier pour les opérations d’exploitation (commerciaux utilisant le back office de Magento) ou pour les opérations d’administration/maintenance.

2 Mise en place du site E-Commerce

Configurer Magento pour qu’il puisse fournir des devis bien établis et ensuite l’alimenter pour que des clients viennent en l’utiliser.

Dans un premier temps nous préparons l’installation pour le site sur un environnement de développement : un serveur Apache HTTPD et un serveur MySQL peuvent suffire pour commencer et installer une instance Magento (la résolution de nom peut être assurée par des entrées dans un fichier host ou par l’utilisation du domaine .local lié au multicast DNS). Le serveur Apache HTTPD doit pouvoir effectuer des réécritures et satisfaire des prérequis techniques de Magento .(http://docs.magento.com/m1/ce/user_guide/magento/system-requirements.html). Au niveau du serveur MySQL, une base avec un compte réseau ayant les droits, est nécessaire. Pour installer Magento, il suffit de récupérer sur le site de Magento l’archive, de la décompresser dans la racine de l’hôte configuré dans Apache HTTPD et appliquer les permissions selon les recommandations de la documentation (http://devdocs.magento.com/guides/m1x/install/installer-privileges_before.html puis http://devdocs.magento.com/guides/m1x/install/installer-privileges_after.html). Un installateur web permettra d’installer Magento. Les informations demandées sont assez triviales (acceptation de la licence, informations de locale, timezone et devise, informations de base de données, d’URL front et back, stockage de session, informations pour créer un login admin en BO). Lors de l’installation, est produite ou indiquée une clé qui permet le chiffrement symétrique de données dans la base et est créé le compte d’administration du back-office. La configuration principale est stockée dans le fichier « app/etc/local.xml ». C’est surtout ce dernier qu’il faudra décliner pour chaque environnement.


Un magento brut, après installation (et sans les données d’exemple)

Une fois réalisée l’installation de Magento, tant que tout le code est natif, il est nécessaire de rechercher et d’appliquer les patchs disponibles.

Pour les curieux : il est également possible de mettre l’installation de Magento en échec … quand on cherche à utiliser IPv6 : https://www.sodifrance.fr/blog/magento-et-ipv6/

2.1 Configuration de mon “magasin” : faite presque une fois pour toute


Réalisation de la “maison” site E-Commerce : les fondations : l’installation de Magento. La première chape : la configuration initiale de la boutique

Ensuite, nous préparons le site dans le backoffice. Il y a de nombreux éléments à prévoir. Le premier est la mise en place de la structure hiérarchique des « stores ». Magento dispose de trois niveaux de configuration de boutique (en dehors du niveau de configuration global ) :

      • Le website : niveau le plus élevé de configuration. Par exemple nous trouverons des listes de clients séparées (ou bien communes) entre les différents websites à ce niveau.
      • Le groupe de stores : c’est à ce niveau où est définie une catégorie racine et où est proposée une navigation personnalisée.
      • Store : gestion de la valeur des attributs EAV.


La hiérarchie des magasins dans la BD de Magento

Lors de son installation, Magento crée par défaut deux websites, deux store groups et deux stores, en raison de la différence entre le front office et le back office.


Dans le cadre de la tirasse, nous resterons sur une boutique domiciliée en France qui prévoit de vendre uniquement à des clients résidant en France. Il n’y a pas de raison de faire des vues séparées pour les différentes typologies de clients car les arguments qui intéressent une typologie pourraient aussi être pris en considération par une autre typologie. De ce fait, la structure par défaut de Magento convient.

La configuration de Magento consiste en grande partie en des réglages qui sont situés dans le back office, dans le menu Système, Configuration. Ce système de configuration constitue un pilier de Magento, utilisant un système générique de stockage de configuration, avec possibilité de changer la configuration en fonction du contexte. Les éléments de configuration eux-mêmes sont hiérarchisés : on trouve d’abord la notion de section, qui est la page de configuration sur laquelle on se trouve, puis la notion de groupe (les zones centrales qui peuvent s’étendre ou se réduire), puis la notion de champ de configuration.
Il va tout d’abord falloir faire la configuration de base de la boutique et parcourir les différents éléments de la configuration pour régler les informations sur les pays desservis, les informations de contact liées à la boutique, le header et le footer des pages, les adresses mails à employer … : c’est dans le groupement « General » qu’il y a le plus de configuration initiale à faire. Ensuite, dans les groupements Catalog et Customer, il s’agit plutôt de vérifier les options de Magento et éventuellement les adapter à son mode de fonctionnement métier, notamment pour désactiver les fonctionnalités non voulues (la gestion des stocks par exemple, dans le cadre de la tirasse). Il faut penser à bien sauvegarder chaque section avant de passer à la suivante. Mention spéciale pour les templates d’adresses (Customers, Customer Configuration) qu’il convient de configurer pour avoir une présentation des adresses conforme aux standards postaux (surtout pour la position du code postal).


Les murs porteurs : les réglages liés aux ventes : savoir établir un devis

Le groupement de section Ventes est assez critique, car il permet notamment de configurer au moins partiellement les moyens de livraison et de paiement. En outre, certains réglages d’affichage doivent également être configurés avec soin, en particulier l’affichage des prix en HT ou en TTC et ce, dans les différents endroits où ils sont présents (fiche produit, panier, commande, facture, …).

Pour pouvoir configurer Magento correctement, il faut avoir une bonne vision de son fonctionnement, notamment en ce qui concerne le tunnel de vente et les collecteurs de totaux. En pratique, les différents utilisateurs sont reconnus par leur cookie de session. La session de l’utilisateur se divise en plusieurs namespaces et l’un des namespaces (checkout) contient l’ID du devis (quote) en cours pour l’utilisateur, qu’il soit identifié ou non. En cas de modification du panier (ajout, suppression, modification d’article), mais également en cas d’affichage du panier (checkout/cart), les totaux sont recalculés. A cette fin, les articles sont associés à une adresse de livraison (il n’y en a généralement qu’une), ou de facturation. Le système charge en mémoire les éléments constitutifs du devis, remet les totaux à 0, puis lance des collecteurs de totaux par adresse. Les collecteurs sont lancés successivement, dans un ordre “plus ou moins” précis (l’ordre des collecteurs peut être régi soit par des contraintes, qui indiquent que tel collecteur doit passer avant tel autre, mais il est également possible de fixer leur ordre numériquement et dans ce cas, l’ordre est alors figé). Parmi les collecteurs, on distingue les collecteurs travaillant sur les articles “nominaux” (c’est-à-dire, les articles récurrents), des articles non nominaux, qui sont les articles que l’on rencontre usuellement. Il y a un grand nombre de collecteurs qui sont lancés, plus ou moins spécialisés, mais on peut résumer globalement le fonctionnement à un calcul du prix HT de l’article et de la ligne de commande, puis le calcul des frais de livraisons, l’application des promotions, le calcul des taxes et enfin le calcul du grand total. Connaissant ce fonctionnement interne, on en déduit qu’il est préférable d’insérer les prix en HT et d’appliquer les promotions sur les prix HT, de sorte à éviter des complexités comme le recalcule de l’effet d’une promotion en HT en se basant sur les réglages généraux du magasin pour identifier les taxes qui devraient être appliquées.

La justesse du devis dépend donc également de l’étape dans le tunnel de vente. Celui-ci est usuellement initié par l’affichage du panier, puis le client se logue, si ce n’est déjà fait, les adresses de livraison et de facturation sont renseignées, le moyen de paiement est choisi et les conditions générales de ventes acceptées avant de payer. Après le paiement, une page de confirmation de commande sert de validation terminale.

Le tunnel de vente peut être personnalisé. Il y a tout d’abord deux types de tunnels :

      • le tunnel onepage, prévu pour les cas classiques, où on n’a qu’une seule adresse de facturation et une seule facture de livraison. Ce tunnel fonctionne à grands renforts de javascript et d’ajax, de sorte qu’effectivement le client ne voit pas de changement de page dans son navigateur.
      • le tunnel multishipping, qui lui passe par plusieurs pages distinctes, avec une page par étape. Ce mode est néanmoins rarement utilisé.

A côté de cela, certaines étapes peuvent être supprimées : par exemple, si la passation des commandes en mode invité est autorisée, alors la nécessité du login n’est plus requise. Cependant, ceci peut avoir des conséquences même au niveau métier, car des commandes passées en mode invité ne sont pas liées à un compte, donc l’utilisateur ne dispose pas d’historique de vente et ne dispose donc pas des facilités liées ( par exemple la consultation de ses commandes, voire factures, depuis son espace client, ou la fusion d’une préparation de panier en mode authentifié avec le panier non authentifié au moment du login). Si les produits sont téléchargeables, Magento prévoit même la possibilité de ne pas autoriser de passer en commande invité pour les commandes avec de tels produits. Techniquement, le passage de commandes en mode invité est également assez impactant dans le processus de commandes, car les informations d’objet « customer » ne seront pas utilisables et il faut donc tout stocker dans la session et tout récupérer depuis cette dernière.

Enfin, il est également possible de ne pas imposer l’adhésion explicite aux conditions de ventes. Les étapes nécessaires à la réalisation de l’achat peuvent facilement être allégées et cela peut accroître la conversion de panier en commande pour l’utilisateur. Mais il faut bien comprendre, accepter et prendre en charge les conséquences liées à ce regain de spontanéité.

Dans le cadre de la tirasse, le tunnel de onepage (qui est implémenté sur une seule page avec des appels AJAX) est suffisant, puisqu’il n’y a pas de livraison physique. De plus, aucun mode de livraison n’est requis (produit virtuel). Etant donné que divers aléas peuvent survenir lors d’un achat - toujours au plus mauvais moment - il est plus judicieux de rendre le passage “Création compte client” obligatoire de sorte à pouvoir éventuellement leur reproposer le téléchargement de leurs produits virtuels. En ce qui concerne les affichages, nous montrerons aux acheteurs à la fois les montants HT et TTC, pour leur fournir une information complète par rapport à la valeur fixée (ou tout du moins estimée) du produit. Étant donné que les dons peuvent, en fonction de leur destinataire, donner droit à des réductions fiscales relativement importantes, ce sera déjà une manière de sensibiliser les clients aux problématiques fiscales et éventuellement d’ajuster le don réel qu’ils feront aux œuvres caritatives.

Concernant le moyen de paiement, son implémentation est généralement réalisée par l’ajout d’un module spécifique à Magento et la désactivation des moyens de paiement natifs non souhaités. Généralement, les prestataires de paiement fournissent 3 types d’environnement :

      • un environnement bac à sable, qui est particulièrement utile pour les développeurs pour effectuer la majorité du travail d’adaptation de la solution de paiement à l’existant,
      • un environnement de préproduction, qui sera utile pour faire des tests de bout en bout et permettra de valider dans le temps le bon fonctionnement du tunnel de paiement complet,
      • Un environnement de production

A ce propos, le mode de paiement Promesse de don est un mode assez inédit, qui nécessitera un développement spécifique.

Configuration des taxes

La tuyauterie : savoir bien brancher les taux, les clients, les produits … et voir des taxes en sortie !

La configuration des taxes sous Magento est relativement complexe à mettre en oeuvre, car elle cherche à pouvoir s’adapter à divers besoins métiers. Elle s’inscrit dans une démarche mêlant la configuration des produits, des clients, des zones géographiques et des taux.
Configuration des clients : les clients peuvent être répartis dans des groupes et ces derniers permettent de faire des différences au niveau des prix (par exemple, des règles de promotion peuvent ne s’appliquer qu’à un certain groupe). Deux groupes existent par défaut : le groupe général des clients et le groupe des clients non authentifiés.

Cela est suffisant pour la tirasse.

Configuration des classes de taxe : les classes de taxe permettent de grouper ensemble des produits qui ont les mêmes caractéristiques fiscales. Il existe un groupe par défaut pour les produits.

A nouveau, une seule classe de taxe suffit pour le projet.

Configuration des calculs de taxe : le premier élément à configurer se trouve dans la section Taxes, groupe Classes de Taxes, champ taxe de classe pour la livraison : positionnement à la même classe que pour les produits.

Groupe des paramètres de calcul : les prix de catalogue et les prix de livraison seront indiqués en hors taxe, les taxes sur le prix unitaire seront calculées par rapport à l’adresse de livraison et les réductions seront appliquées sur les prix avant le calcul de taxe. Le calcul de taxe se fera sur le prix après réduction. Pour les réductions, elles sont en hors taxe.
Enfin, la destination par défaut est configurée pour le calcul des taxes à la France, dans le prochain groupe.

De la sorte, les taxes sont appliquées le plus tard possible et cela réduit les problématiques d’arrondis de centimes et simplifie les calculs (notamment, il n’y a pas besoin de calculer une estimation du HT à partir du TTC en se basant sur les réglages de Magento).

Configuration des zones de taxes : les produits vendus sont potentiellement livrés à un client. Ce client a une adresse de livraison, ou au minimum de facturation. Ce lieu est utilisé comme référence pour les taxes à appliquer : ainsi, pour chaque taux de taxe applicable est utilisé une zone de taxe, qui inclut le taux de la taxe et la délimitation géographique du lieu.

Il est toujours intéressant de disposer de la configuration TVA au cas où : nous pouvons configurer les différents taux existants en spécifiant le pays France, pour la France métropolitaine.

Configuration des règles de taxes : il existe des classes de taxe produit, des groupes de clients et des zones de taxe : les règles de taxes constituent l’intersection entre ces trois éléments, en autorisant en plus la définition un ordre d’application des taxes, ce qui permet si nécessaire de mettre en œuvre des taxes composées (prise en compte de taxes appliquées à un prix pour appliquer d’autres taxes).

Nous supposons avoir besoin d’une règle unique, le produit n’étant destiné qu’au marché français.

Configuration des mails

Faire des fenêtres donnant sur … l’intérieur : l’envoi de mails aux petits oignons

La configuration des mails est importante, car il s’agit souvent de communications automatiques envoyées à des clients. Au niveau de Magento, deux mécanismes sont mis en jeu dans l’envoi des mails dits “transactionnels” :

      • l’identité de l’expéditeur, réglée depuis le BO et stockée dans core_config_data. Celle-ci est également sélectionnable pour les mails transactionnels et cette sélection est également stockée dans core_config_data
      • Création du modèle de mail qui sera envoyé : un tel modèle de mail contient des champs dynamiques (le nom du client, le numéro de commande, …), qui seront injectés avant l’envoi du mail. Les mails peuvent être personnalisés via le code (les modèles se trouvent généralement dans « app/locale//template/email ») et référencés dans les configurations (fichiers config.xml). Ils peuvent aussi éventuellement être personnalisés par la suite depuis le BO et stockés par le SGBD. La sélection du modèle de mail sera également conservée dans core_config_data.

La difficulté de la configuration des mails est surtout liée à la création de bons modèles pour les mails, dans un objectif de maintenance facilitée. Il est intéressant de chercher à isoler les en-têtes et les pieds des mails pour les réutiliser dans les différents modèles. Et à côté de cette rigueur de conception, il y a également la difficulté inhérente au contenu métier du mail.

Configuration de l’aspect esthétique

Crépis ou briques apparentes ? Une question d’esthétique

L’aspect esthétique du site est un élément important, puisqu’il peut séduire ou rebuter un internaute. En ce qui concerne ce sujet, il s’agit en premier lieu de penser à l’ergonomie du site pour qu’il soit adapté à la clientèle qu’il cible. Le design du site est géré à l’aide de package comportant des thèmes. Un thème peut regrouper des images, du js, du css et même des layouts et des templates qui peuvent modifier les éléments affichés à l’écran. Magento propose par défaut un thème de base, un thème blank (vide) et un thème responsive (c’est-à-dire, un thème qui s’adapte à la résolution du périphérique de l’utilisateur). Un système d’héritage de thèmes permet aux designers de ne pas avoir à modifier ou définir l’ensemble des éléments utilisés, seulement ceux qu’ils veulent modifier. Les versions récentes de Magento intègrent des mécanismes de compilation de CSS. Il s’agit donc de ne pas modifier des fichiers qui ont été générés et qui pourraient être écrasés par recompilation. Toutefois, il y a un autre élément à prendre en compte : la maintenance applicative. Si le thème choisi surcharge les templates “par défaut” de Magento, les surcharges ne seront peut-être pas maintenues “au jour le jour” par leur développeur pour tenir compte des derniers patches. De ce fait, ce travail de mise à niveau peut revenir, au moins dans une partie, au développeur chargé de la maintenance et peut alourdir les coûts d'exploitation du site.


Pour la tirasse, nous chercherons sur MagentoConnect un thème gratuit et libre de droits pour adapter uniquement le (S)CSS..

2.2 Le catalogue

La notion d’EAV

Entity Attribute Value, ou les structures génériques dans Magento

Le catalogue réunit en pratique deux éléments : la gestion des produits et la gestion des catégories. Les produits, tout comme les catégories, ont sous Magento une architecture un peu spéciale, appelée EAV (Entity Attribute Value). L’idée est de pouvoir dynamiquement ajouter des attributs à un objet sans toutefois modifier le schéma de BD. L’ensemble des types EAV, de même que les attributs disponibles pour chaque type est défini dans des tables spécifiques. Ces informations permettent de stocker les valeurs des attributs dans des tables de stockage. Ainsi, pour un produit, on aura par exemple la table catalog_product_entity, qui contiendra certaines informations de base nécessaires à identifier l’objet, puis des tables comme « catalog_product_entity_varchar », « catalog_product_entity_int », etc. qui vont stocker l’ID de l’attribut, le scope de l’attribut, l’ID du produit et finalement la valeur de l’attribut. Les attributs sont classables en groupes et en sets d’attributs, ce qui va influencer l’affichage des attributs, surtout dans les produits. En fonction des types d’entité, des informations supplémentaires concernant les attributs peuvent être requises, par exemple pour savoir si l’attribut peut être affiché en FO, ou si l’attribut peut être utilisé dans les comparaisons de produits : à cet effet, il existe des tables supplémentaires pour stocker ces informations.

Les catégories sont également implémentées en EAV. Néanmoins, il faut bien voir que pour récupérer des propriétés d’un objet de cette manière, il est souvent nécessaire de faire des requêtes contenant un grand nombre de jointures, ce qui nuit aux performances. C’est pour cela que Magento dispose également d’une possibilité d’index plat sur certains objets EAV : il s’agira de créer une table qui va contenir tout ou partie des valeurs des propriétés de l’objet et ce par store.

Tous les produits ne se ressemblent pas : choisir ou créer son type

En plus de la notion d’attributs, les produits disposent d’une notion de type. Le type du produit influe sur certaines opérations réalisables sur le produit, opérations qui sont implémentées notamment dans la classe représentant le produit. En pratique, sous Magento, on dispose d’un certain nombre de types de produits :

      • Simple : un produit quelconque : type le plus souvent utilisé
      • Configurable : il permet de présenter une série de produits représentant des déclinaisons d’un même produit. L’exemple souvent vu est au niveau vestimentaire un T-Shirt qui est proposé en plusieurs coloris et tailles. Chaque combinaison coloris/taille pourra être intégrée sous forme d’un produit simple et on laissera choisir la combinaison souhaitée à l’utilisateur au niveau du configurable
      • Groupé : on décide de vendre certains produits ensemble, dans une configuration “fixe”
      • Bundle : on décide de vendre certains produits ensemble, mais l’utilisateur a une certaine latitude de décision dans la composition du bundle
      • Virtuel : des produits qui n’ont pas de tenant physique
      • Téléchargeables : produits numériques.

En fonction du type de produit, il est possible d’adjoindre au produit des options qui pourront être configurées par le client. Il est fondamental de choisir un type de produit approprié pour représenter les entités qu’on veut vendre et si nécessaire, créer son propre type de produit, son ou ses propres jeux d’attributs, ainsi que les attributs qui décrivent le produit. Au niveau de la création de ces éléments, tout comme la création de produits, trois approches théoriques sont envisageables :

      • soit créer les éléments manuellement dans une base de données de production, puis restaurer un dump de production en pré-production et fournir le dump aux développeurs pour qu’ils puissent avoir une base à jour : c’est faisable si les adaptations nécessaires sont réalisables directement en Back Office
      • soit créer les éléments via des installateurs depuis le code et c’est la mise à jour du code qui déclenchera la création des éléments dans les différents environnements, allant de l’environnement de développement jusqu’à l’environnement de production
      • une autre possibilité est la création d’un système d’importation de produits.

Bien entendu, comme la tirasse est téléchargeable, nous utiliserons le produit téléchargeable comme type de produit. Et comme il s’agira d’un nouveau site, nous mettrons directement en production une base de données pré-configurée.

La création de produit nécessite l’indication d’un certain nombre d’informations, comme le SKU du produit, son prix, mais aussi la description courte et la description normale. En ce qui concerne les descriptions, il faut garder à l’esprit qu’elles sont essentielles, car un effort de rédaction pourra faciliter le référencement naturel de la page, d’une part et convaincre les acheteurs d’autre part. Il ne faut donc pas sous-estimer le temps nécessaire pour bien renseigner une fiche produit. Il est d’ailleurs même possible de différencier les pages produits les unes des autres par des présentations spécifiques, en agissant sur le layout d’une page produit.


Par ailleurs pour un produit tel que la tirasse, des vidéos peuvent également être très utiles, pour démontrer l’utilisation du produit ; une inclusion de vidéo peut être effectuée via de la saisie de code HTML (par exemple, un iframe vers youtube).

La fiche produit comporte également une gestion d’inventaire. Il faut prendre garde à bien configurer ce point, car une mauvaise configuration pourrait rendre simplement l’article non vendable. De même, il faut également faire attention au statut (activé, désactivé) et à la visibilité du produit, le produit pouvant être visible ou non dans une recherche ou par le catalogue.

Enfin, la fiche produit permet également de définir des relations avec d’autres produits, comme des produits connexes ou de substitution.

Pour les curieux : il y a d’autres façons de présenter des produits … on peut aussi chercher à en faire des modèles 3D, par exemple via la photogrammétrie :
https://www.sodifrance.fr/blog/photogrammetrie-utilisation-possible-avec-magento/

Les catégories et la navigation

S’y retrouver dans un choix pléthorique : la présentation de l’organisation du site

Les catégories permettent de regrouper les produits et offrent de la sorte un classement des produits qui sera utilisé par la navigation. Ainsi, les catégories forment une arborescence depuis une catégorie racine (non affichée en Backoffice) et nous pouvons définir pour chaque groupe de stores la catégorie racine qui va permettre la navigation dans le site et qui sera également utilisée pour générer le sitemap. Chaque produit peut être dans aucune, une ou plusieurs catégories.

En ce qui concerne la navigation, les catégories (tout comme les produits et les pages CMS d’ailleurs) peuvent se voir attribuer une URL spécialisée, qui est plus parlante pour l’utilisateur (et pour le moteur de recherche) : il s’agit du mécanisme d’URL rewriting, qui est un mécanisme pour identifier les pages spécifiques, de sorte à ne pas être gêné par la forme “canonique” des URL magento (routeur/controller/action/, puis nom et valeur de paramètres).
De même, il est possible d’activer sur les catégories le filtrage des produits selon des critères définis par l’utilisateur, ce qui peut permettre dans certains cas à un utilisateur d’accéder plus rapidement au produit recherché.


Comme indiqué au début de l’article, les catégories pourront servir pour présenter la tirasse selon plusieurs angles de vue.

La recherche

Magento intègre une possibilité de recherche se basant sur les attributs qui sont marqués comme “utilisable” dans une recherche. L’utilisateur peut faire des recherches précises en se basant sur ces attributs et les produits qui en résultent sont alors affichés. Une recherche rapide est également disponible, où l’utilisateur indique uniquement le texte qu’il recherche.
Ces recherches servent à présenter des résultats qui sont des produits et le type de recherche est soit un like, soit une recherche fulltext, ce qui signifie que ces recherches doivent rester relativement simples et n’offrent pas les possibilités d’un moteur Lucene par exemple. C’est pour cela que la version Enterprise de Magento permet également d’utiliser une instance SOLR et permettrait par exemple des recherches avec des termes pondérés.
On notera que d’autres approches sont éventuellement envisageables, puisqu’une implémentation d’un moteur Lucene est déjà présente dans les librairies Zend. D’autre part, des possibilités d’utiliser des moteurs de recherche externes existent (Google Custom Search par exemple).

Dans le cadre de la tirasse - produit unique s’il en est - les recherches peuvent porter sur des éléments précis dans les pages HTML mais aussi surtout dans des documents annexes, par exemple dans des fichiers PDF de documentation. De ce fait, il semble opportun de considérer des éventuelles évolutions du site e-commerce pour interroger un moteur externe qui indexera non seulement l’ensemble des pages produits, mais également les pages CMS et les documentations. La mise en place d’un tel moteur de recherche dépassera donc le cadre strict d’une boutique e-commerce.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.