La page produit, c’est simple…

Rien de plus simple qu’une page produit !

Pourquoi se « faire des noeuds » pour rien ?

C’est :

  • Un nom de produit
  • Un texte de description
  • Quelques photos

Le produit est rangé quelque part, dans une catégories.

Voilà, fin du débat.

Heu, c’est un peu court…

Un produit peut être déclinable, en taille, en couleur, et en tout un tas d’autres choses (motif par exemple).

A-t-on une fiche produit par déclinaison ou est-ce la même fiche produit pour toutes les déclinaisons ?

Au fait, le stock, c’est pour une déclinaison…

Et puis pendant qu’on y est, le prix, il peut varier en fonction de certains critères.

Ah, ok.

Et c’est pas fini : a-t-on une seule page pour toutes les déclinaisons ?

La question est simple mais pas la réponse.

Cela dépend des cas.

En général, on a bien une seule fiche produit pour la déclinaison en taille. Pourquoi ? Parce qu’il s’agit d’une variable « technique », qui n’a pas de valeur sur les pages listes par exemple.

Mais ce n’est pas forcément le cas pour d’autres critères, comme une déclinaison par couleur. Suivant les cas, il peut être intéressant d’avoir une fiche produit spécifique par couleur, avec une URL et donc un référencement spécifique. Si le client cherche un pull rouge, c’est pas mal que cette page remonte chez google, non ?

Oui mais si on a 30 couleurs de pull, vous imaginez la tête des pages listes, qui vont être remplies de toutes les déclinaisons de couleur ?

Sur cet exemple, on voit bien que cette simple question a des réponses riches, pour un même site.

Et je n’ai pas parlé du moteur de recherche interne au site, qui doit permettre d’aller directement sur la bonne fiche si l’internaute cherche « pull rouge ».

Et si je reviens sur les tailles, on peut aussi bien améiorer l’expérience client, en permettant des filtres sur les tailles dès les pages listes. Exemple : je ne cherche que des chaussures en 43. ça serait pas mal que, quand je clique sur la chaussure qui me plait, j’arrive directement sur la chaussure en 43, non ?

bon, j’arrête là, parce que, normalement, vous avez compris mon idée : une page produit n’est pas simple du tout ! C’est même réellement un « objet » complexe.

Et je n’ai pas parlé de personnalisation, d’attributs variables, de comparaison de produits, …

Bref, le produit, c’est un monde… un monde modélisé d’ailleurs par des logiciels, qu’on appellent des PIM : Product Information Management. Si je devais concevoir un système e-commerce, je commencerais par là ;).

9 commentaires

  1. Hello, je fais une petite distinction ici, entre la « page produit » et le produit …

    La page produit est … une page.
    Donc, même si c’est la partie visible de l’Iceberg – en fait surtout puisque c’est la partie … – elle doit intégrer des dimensions à la fois esthétique ET technique. Ex c’est bien d’avoir une photo très haute définition mais si ca prend 30 secondes à charger … on voit l’idée.

    Le produit, lui doit disposer de beaucoup plus « d’attributs » que ce qui est peut être affiché sur la page produit, ex en ce qui me concerne je suis sensible aux composés volatiles et autres poisons qui entre dans la fabrication d’un produit, j’aimerais donc trouver des informations qui m’informe de cela, pas nécessairement en « première information ». L’idée ici c’est que la traçabilité, la composition, le packaging, etc. sont des infos qui doivent être présentes sans forcément être en « page produit ». 1 autre illustration – moins orientée client final, sont les informations de conditionnement, importantes pour transporteur, ou pour un grossiste, pas pour le client lambda, et ce sont des infos « produit »

    Donc oui, un PIM peut être super pratique, avec cerise sur le gâteau, la possibilité de déléguer la gestion de l’info à la source – c’est le fabricant de pull qui renseigne la description, les composants, …, c’est le logisticien qui renseigne sur le conditionnent, les délais d’appro … Un rêve !

    Comme je n’ai pas encore trouvé de pièce à 1 face, le revers de la médaille, c’est que la mise en place de ca, c’est lourd et en plus il y a des recouvrements entre le PIM et le eCommerce voire le CRM (si on sait gérer des info produits complexes, on sait gérer des infos clients non 🙂 ) – donc à la fin on se retrouve avec un Système d’Information complexe avec pas mal de recouvrements (du moins en théorie) fonctionnels, ce qui génère beaucoup d’arbitrages et comme nous parlons ici de logiciels, de mise en œuvre informatique, il y aura des retards, des points chauds, bref pas mal de frictions … et tout cela représente de l’argent, beaucoup …

    Mais qui a dit que c’était facile d’être consultant en eCommerce 🙂

  2. Très bonnes remarques 🙂 A mon sens, savoir les produits qu’on rend visibles et « non visible individuellement » comme sur un certain CMS, dépend de ce qu’on a au total.

    Si par exemple j’ai une catégorie Pulls avec 2 modèles et 2 déclinaisons de couleurs, si j’affiche juste les modèles (pas les déclinaisons) dans les catégories, mon internaute va avoir l’impression que je ne propose rien, juste deux pulls, alors que si j’affiche les déclinaisons de couleurs ça m’en fait déjà 4. Ce genre de détail est important au cas par cas mais au niveau de la catégorie je pense. D’ailleurs l y a une coquille dans le début de l’article où tu évoques « une catégories ».

  3. @Olivier> Merci 🙂

    @Jean Michel> Oui, mais bien analyser les choses à partir du besoin Front n’est pas un si mauvais départ que ça 😉

    @Fred> Effectivement le mieux est de pouvoir faire des réglages, au niveau du CMS. Mais certaines informations doivent descendre un peu plus profondément dans le système d’information, d’ou la logique de PIM

  4. Bon article quoi qu’un peu court, je rigole 🙂
    Il est bien simple à comprendre ce qui me va parfaitement vue que je ne suis pas douée en matière de ecommerce mais je compte m’y mettre!

    a bientôt

    Alexandra

  5. Hello François,

    il serait intéressant que tu fasses un article plus complet sur les pim, car si je vois l’idée, j’aimerais comprendre plus en détail ce qu’apporte un pim par rapport au backend d’une solution e-commerce style magento.
    Aurais-tu des exemples de solutions pim? J’avais entendu parler de pimcore à l’époque.

    Comment un pim s’intègre dans le système d’information ? est-ce une brique supplémentaire ? on aurait un erp, un crm, un pim, …
    Du coup il faut prévoir des flux pour relier le pim aux autres briques ?

    Bref, si tu as des informations à apporter sur les pim, je suis preneur 😉

  6. @Remyma, très difficile de répondre à vos questions via 1 blog. des PIM ou Master Data Management, il en existe chez presque tous les éditeurs (Hybris, Oracle, IBM) ou même open source, PIMCORE en est 1. Comme toujours en la matière, le choix dépend avant tout des besoins et des moyens.

    Comme je le disais précédemment, les fonctionnalités d’un MDM se recoupent, pour certaines avec les fonctionnalités d’un backend de logiciel de eCommerce pour la gestion des info produits, mais elles étendent la notion « d’info produit » bien au delà de ce que l’on gère, généralement, en eCommerce. le PIM peut également servir d’éditeur pour un catalogue papier ou des prospectus, il peut assurer la traçabilité des informations(gestion de version), voire leur gestion en délégation (le producteur de l’info, met à jour cette dernière, pas le consommateur de l’info ou celui qui la relaye). 1 MDM peut servir de système de gestion des Offres (vous constituez vos packages ou bundle via le MDM), etc.

    Pour dire que je suis pas sectaire je vous communique un lien http://msdn.microsoft.com/en-us/library/bb190163.aspx
    (moi qui suis plutôt Java/J2EE un lien de MS !!!)
    Pour compenser un lien vers big blue : http://public.dhe.ibm.com/software/data/sw-library/smart-book/index.htm

    En ce qui concerne l’intégration, oui le PIM / MDM est une brique comme l’est l’outil de gestion des contenus (CMS) ou celui de la relation Client (CRM) ou de la facturation/valorisation (ERP) ou un système de billing et de logistique, et oui tout se doit de communiquer ensemble.

    Principe de base : Celui qui produit l’info est le maitre de cette info, dans la pratique il arrive que les données soient dupliquées, c’est toujours une source d’ennuis.
    Après en terme d’architecture, il faut absolument éviter la multiplication des interfaces « One To One », trop souvent encore je vois des SI qui se construisent sur la base de « On a que 3 briques, c’est pas compliqué » et puis 2 ans après il y a 7 briques ou plus et le système est devenu le cauchemars de l’équipe technique pour ce qui est de l’évolution ou des mises à jour. Donc, privilégier une approche « Service » via un bus middleware (Fusion, IBM ESB, ou autre, il en existe pléthore), est un gage de pérennité et d’évolutivité (même si bien d’autres critères entrent en jeu)

    En espérant que cela aide un peu (j’ai conscience comme je l’indiquais plus tôt, de la superficialité de cette réponse, dont je vous prie de m’excuser)

Laisser un commentaire

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