Recommandations produits dynamiques dans Magento 2 : des profils au lieu de relations rigides

Dans de nombreux projets Magento 2, la question des recommandations produits part d’une hypothèse simple : il faut afficher au client quelques produits supplémentaires sur la fiche produit, dans le panier ou au moment du checkout. Le problème apparaît très vite. Les mécanismes standards related, upsell et cross-sell de Magento sont utiles, mais dans la pratique ils se révèlent souvent trop rigides pour les besoins réels d’implémentation.

Une boutique ne veut évidemment pas afficher les mêmes produits partout et dans tous les cas. Il faut un scénario pour un produit simple, un autre pour un configurable, un autre encore pour une campagne saisonnière, et un autre enfin pour un panier qui contient plusieurs produits différents. Du point de vue des agences et des équipes d’implémentation, cela signifie généralement une chose : les exceptions s’accumulent, les conditions personnalisées apparaissent, et l’on ajoute couche après couche de code de plus en plus difficile à maintenir.

Kowal_RelatedProductsProfiles a justement été conçu pour résoudre ce problème autrement. Au lieu de construire la logique autour de relations produit-produit individuelles et liées manuellement, le module introduit la notion de profil de recommandation. C’est le profil qui définit où il doit agir, dans quelles conditions il doit s’exécuter, comment sélectionner les produits et comment les rendre. Les recommandations deviennent ainsi une couche configurable, et non une nouvelle collection d’exceptions ponctuelles intégrées au code du projet.

Le module est disponible ici : Automatic related products for Magento 2.

Pourquoi les listes standard de Magento ne suffisent souvent pas

Les listes natives related, upsell et cross-sell fonctionnent bien dans les boutiques simples ou dans les contextes où le merchandising est géré manuellement par l’équipe e-commerce. Dans les implémentations réelles, cependant, des scénarios apparaissent très vite et ne sont pas couverts par le modèle standard :

• afficher des recommandations uniquement pour un groupe de clients donné,
• activer une liste précise seulement sur une période définie,
• relier les produits à partir d’attributs de catalogue au lieu de relations manuelles,
• avoir un comportement sur la PDP, un autre dans le panier et un autre au checkout,
• insérer une liste à un emplacement précis du layout du thème sans réécrire toute la vue,
• remplacer partiellement ou totalement les listes natives de Magento par une logique propre au projet.

Pour les agences, cela signifie en général deux problèmes. D’abord, le mécanisme standard doit être entouré de conditions supplémentaires. Ensuite, chaque nouveau besoin métier commence à produire sa propre exception. À un certain moment, au lieu d’un mécanisme cohérent de recommandation, on obtient un ensemble de contournements sans lien entre eux.

Les profils comme couche de logique merchandising

L’idée la plus importante du module est d’abandonner une vision centrée sur une simple liste de produits pour la remplacer par un profil de recommandation.

Le profil est une entité de configuration distincte. Il définit :

• où il doit fonctionner,
• pour quelle boutique et quel groupe de clients il est actif,
• quel produit doit servir de contexte,
• quand le profil doit se déclencher,
• comment sélectionner les candidats,
• comment réduire le résultat,
• comment trier les produits,
• comment les afficher,
• et s’ils doivent également alimenter les listes natives de Magento.

Du point de vue de l’implémentation, c’est un vrai changement de qualité. Au lieu de préparer du code personnalisé séparé pour chaque placement, on peut construire un ensemble de profils correspondant à différents scénarios métier. Ce modèle est plus simple à maintenir, plus facile à faire évoluer et bien plus lisible pour les équipes qui reprendront le projet après sa mise en production.

Où le module apporte un avantage réel en implémentation

L’endroit le plus évident est la fiche produit. C’est là qu’on veut le plus souvent afficher des produits de la même collection, dans un style similaire ou issus de la même ligne de communication. En pratique, pourtant, la PDP est rarement le seul endroit où les recommandations ont du sens.

Le panier ouvre un scénario complètement différent. Ce n’est plus un moment d’inspiration, mais une étape où l’on peut travailler sur l’augmentation de la valeur du panier. Ici, les profils qui suggèrent des accessoires, des compléments, des ajouts moins coûteux ou des produits d’une autre base d’assortiment, tout en restant liés à ce que le client a déjà choisi, fonctionnent particulièrement bien.

Le checkout est une autre étape qui demande de la prudence. Toutes les boutiques ne veulent pas y développer le merchandising, mais pour certaines implémentations cela peut être un bon endroit pour une liste courte et simple de produits qui soutient l’AOV, à condition que la logique et le rendu soient très contrôlés.

Et les possibilités du module ne s’arrêtent pas là. Un profil peut aussi alimenter les blocs natifs de Magento :

• Related Products,
• Upsell Products,
• Crosssell Products.

L’important, c’est que l’intégration ne se limite pas à un simple remplacement de liste. Pour chacun de ces mécanismes, on peut décider si les résultats du profil doivent être ajoutés aux produits natifs (append) ou les remplacer complètement (replace). Pour les agences, c’est très pratique, car cela permet d’introduire la logique par étapes sans devoir réécrire immédiatement toute l’expérience d’achat.

Comment fonctionne la logique du module

Même si le formulaire du profil est assez riche, le modèle de fonctionnement peut être décrit clairement. Le module passe à chaque fois par plusieurs étapes successives.

D’abord, le placement est déterminé, c’est-à-dire l’endroit où le profil s’exécute. Une logique sera utilisée sur la fiche produit, une autre dans le panier. Ensuite, le produit contextuel est sélectionné. Sur la PDP, il s’agit généralement du produit courant, tandis que dans le panier et au checkout il faut décider quel produit du quote devient le point de référence.

Une fois que le module connaît le contexte, il vérifie les conditions d’activation. C’est le premier filtre, qui répond à la question suivante : ce profil doit-il vraiment s’exécuter dans la situation actuelle ?

Si les conditions sont remplies, le module passe aux matching rules. C’est là que se produit le véritable appariement. Les attributs du produit contextuel sont mis en correspondance avec ceux des produits candidats afin de trouver des produits de la même collection, série, illustration, catégorie ou toute autre caractéristique pertinente d’un point de vue métier.

Après le matching, le résultat peut encore être réduit à l’aide de filtres statiques sur les produits cibles. C’est un endroit pratique pour limiter la liste à certains types de produits, niveaux de visibilité, statuts ou même bases de produits sélectionnées.

À la fin, les produits sont triés, limités au nombre configuré, puis rendus soit dans une zone de layout dédiée, soit dans les blocs natifs de Magento.

En pratique, cela signifie que le module ne repose pas sur une simple relation produit-produit, mais sur une séquence de décisions pilotables depuis l’administration.

Créer un nouveau profil : comment se présente le travail avec le formulaire

La plus grande force du module apparaît lorsqu’on considère le formulaire de profil non comme une simple liste de champs, mais comme un outil de modélisation d’un scénario merchandising.

Le processus commence par la section générale. Name est le libellé administratif qui aide l’équipe à retrouver le profil dans le back-office. Code est l’identifiant technique. C’est cette valeur qu’il vaut la peine d’utiliser dans les logs, dans la communication projet et dans la documentation d’implémentation. Enabled permet de désactiver rapidement un profil sans supprimer sa configuration, et Sort Order détermine l’ordre dans lequel les profils sont évalués au sein d’un même placement.

La deuxième section concerne le périmètre de fonctionnement. C’est ici que l’on choisit les placements, les store views et les groupes de clients. Du point de vue de l’implémentation, c’est essentiel, car cela permet de conserver un mécanisme unique tout en différenciant le comportement entre boutiques, langues ou segments clients.

Le champ Context Strategy est particulièrement important. Sur la fiche produit, la logique est simple, puisque le module travaille avec le produit courant. Dans le panier et au checkout, il faut toutefois définir quel élément du quote devient le contexte. En pratique, cela peut être le premier produit, le dernier ajouté ou le produit le plus cher. Ce petit champ a un impact très fort sur le résultat final, surtout dans les paniers contenant plusieurs lignes différentes.

Les champs From Date et To Date permettent de limiter un profil à une fenêtre temporelle précise. Grâce à cela, le même module peut aussi gérer des campagnes saisonnières et des actions commerciales de courte durée sans ajouter d’interrupteurs spécifiques.

Activation Conditions, Matching Rules et Target Product Filters

Ce sont précisément ces trois sections qui portent la logique métier du module.

Activation Conditions doivent être considérées comme la couche d’entrée. C’est ici que l’on définit quand un profil doit réellement s’activer. Si, par exemple, un profil doit fonctionner uniquement pour des produits d’une base donnée, d’une marque précise ou avec une visibilité catalogue spécifique, ces conditions doivent être posées ici.

Matching Rules sont le cœur de tout le mécanisme. Elles transfèrent les caractéristiques du produit contextuel vers les produits cibles. En pratique, cela signifie qu’on peut dire au module : trouve des produits qui ont le même visuel, la même collection, la même catégorie ou n’importe quel autre attribut pertinent d’un point de vue métier.

Deux champs sont particulièrement importants ici : Required et Empty Value Policy.

Required détermine si une règle est obligatoire. S’il est activé, l’absence de correspondance rejette le candidat. S’il est désactivé, la règle agit davantage comme une couche de réduction supplémentaire, mais un mismatch ne bloque pas tout le résultat. En pratique, c’est essentiel dans les projets où le contexte peut être différent entre la PDP et le panier, par exemple avec un configurable parent sur la fiche produit et un simple child dans le quote.

Empty Value Policy indique au module quoi faire lorsque le produit contextuel n’a pas de valeur dans l’attribut source. La règle peut être ignorée, considérée comme échouée ou alimentée par une valeur par défaut. Ce champ décide souvent de la stabilité du profil dans un catalogue complexe avec différents types de produits.

Target Product Filters représentent la dernière couche de réduction. Ils ne travaillent plus sur la relation contexte-candidat, mais directement sur les produits cibles. C’est un bon endroit pour imposer un statut, une visibilité, un type de produit ou limiter le résultat à certaines familles d’assortiment.

Tri et présentation

Du point de vue de l’implémentation, il n’est pas seulement important de savoir quels produits sont trouvés, mais aussi dans quel ordre et sous quelle forme ils sont affichés.

Le module permet de définir un attribut de tri principal et un attribut secondaire. Cela permet de construire des listes plus prévisibles, au lieu de s’appuyer uniquement sur le comportement par défaut de la collection.

Côté présentation, plusieurs variantes de rendu sont disponibles, notamment grid, slider et compact. Cela permet d’adapter la liste à l’espace disponible sur la page sans créer des types de profils séparés simplement pour modifier le markup ou l’agencement visuel.

Il est également important que le profil puisse piloter indépendamment des éléments comme :

• le prix,
• le prix régulier,
• le bouton d’ajout au panier,
• le nom du produit,
• la description courte,
• le rôle de l’image.

En pratique, cela signifie que le même moteur de recommandation peut être utilisé aussi bien pour des sections plus riches sur la PDP que pour des listes plus discrètes dans le panier ou au checkout.

Alimentation des listes natives de Magento

L’une des fonctionnalités les plus intéressantes du module est la possibilité d’alimenter les blocs natifs de Magento. C’est particulièrement important pour les agences qui ne veulent pas reconstruire tout de suite le frontend existant ou qui travaillent sur des projets où une partie de la boutique repose encore sur les listes classiques related, upsell et crosssell.

Dans ce scénario, le profil n’a pas besoin d’être rendu comme un bloc séparé. Il peut être branché sur la liste native et fonctionner selon l’un des deux modes disponibles.

Le mode append conserve les produits natifs et y ajoute les résultats du profil. C’est une bonne solution là où l’équipe e-commerce veut encore garder une partie des relations définies manuellement, tout en ayant besoin d’une couche supplémentaire d’automatisation.

Le mode replace va plus loin et remplace complètement la liste native par les résultats du profil. C’est une option particulièrement intéressante pour les boutiques qui ne veulent plus gérer les relations manuellement et qui attendent que la logique des profils devienne leur principal mécanisme de recommandation.

Cette architecture apporte une grande flexibilité d’implémentation. On peut introduire le module progressivement, commencer par étendre les listes natives, puis prendre ensuite un contrôle complet sur celles-ci.

Le XML comme couche d’intégration flexible

Du point de vue de l’implémentation, il est très important que le module ne s’arrête pas à la logique de sélection produit. Le contrôle sur l’endroit où les produits sont rendus est tout aussi important.

C’est précisément pour cela que le profil contient des champs XML assignés à chaque placement. Ils permettent d’insérer le résultat du profil dans un conteneur précis ou sous un bloc de layout donné, sans créer un module séparé uniquement pour positionner la liste au bon endroit.

En pratique, c’est très important lorsqu’on travaille avec des thèmes personnalisés. Chaque frontend possède sa propre structure de layout. Certains thèmes déplacent la description produit vers un autre parent, d’autres construisent leurs propres wrappers, d’autres encore refondent presque complètement les blocs produits natifs de Magento. La possibilité de piloter le placement par XML apporte ici un avantage considérable.

C’est cette couche qui fait du module non seulement un moteur de recommandation, mais aussi un outil d’intégration. Pour les agences, c’est un véritable gain de temps, car la méthode d’insertion peut être adaptée à un projet concret sans perturber la logique principale.

Exemples de scénarios d’implémentation

Le scénario le plus simple est la recommandation classique « même collection, autre base ». Un profil peut s’activer pour un produit d’une base donnée et, grâce aux matching rules, trouver des produits avec le même visuel mais appartenant déjà à une autre famille d’assortiment. La boutique peut ainsi promouvoir des ensembles ou élargir l’achat à d’autres types de produits sans construire de relations manuelles.

Le deuxième scénario concerne les accessoires ou compléments dans le panier. Dans ce cas, le contexte peut être le premier produit ou le produit le plus cher du quote, et les target filters limitent le résultat final à des produits qui ont du sens comme extension de l’achat. C’est particulièrement utile là où le cross-sell standard de Magento n’offre pas assez de contrôle.

Le troisième scénario concerne les campagnes saisonnières. Un profil peut fonctionner uniquement sur une plage de dates donnée, seulement pour certaines store views et uniquement pour des groupes de clients sélectionnés. Du point de vue de l’équipe d’implémentation, cela signifie que la campagne peut être construite dans le même mécanisme, sans développer un module promotionnel distinct.

Le quatrième scénario consiste en un remplacement partiel ou total des upsells natifs. C’est particulièrement intéressant pour les boutiques avec un assortiment important, de nombreuses caractéristiques catalogue et sans volonté de maintenir des relations manuelles entre produits.

Pourquoi cette approche passe bien à l’échelle en maintenance projet

Pour les agences, la question la plus importante n’est pas seulement « est-ce que cela fonctionne ? », mais aussi « sera-t-il encore maintenable dans six mois ? ».

C’est justement ici que l’approche basée sur les profils présente son plus grand avantage. La logique n’est pas dispersée entre des observers séparés, des plugins et des classes dédiées à des cas particuliers. À la place, on a un modèle de configuration unique et un moteur de recommandation unique qui peuvent évoluer par couches.

Cette organisation apporte plusieurs avantages :

• il est plus facile de transmettre le projet à l’équipe de maintenance,
• il est plus facile d’ajouter de nouveaux scénarios sans réécrire les existants,
• il est plus facile de diagnostiquer le comportement des profils parce que la logique est concentrée en un seul endroit,
• il est plus facile de travailler avec des frontends personnalisés grâce à la couche XML,
• il est plus facile de séparer les décisions métier des détails d’implémentation.

En pratique, cela signifie que le module apporte à une agence non seulement de nouvelles possibilités pendant l’implémentation, mais aussi une base saine pour la suite de l’évolution du projet.

Résumé

Kowal_RelatedProductsProfiles n’est pas seulement un mécanisme pour afficher une liste de produits de plus sur une page. C’est un outil de conception de scénarios de recommandation dans Magento 2.

Pour les équipes d’implémentation et les agences, trois éléments comptent surtout. D’abord, le module permet de construire la logique de recommandation autour de profils, et non d’exceptions ponctuelles. Ensuite, il donne le contrôle sur le placement, le contexte, la sélection produit et le rendu. Enfin, il s’intègre bien dans la réalité des projets, où il faut concilier attentes métier, contraintes du thème et besoin d’évolution future de la boutique.

Si un projet demande plus que de simples relations produit définies manuellement, ce modèle offre bien plus de liberté que les mécanismes standards de Magento. Et c’est précisément là que réside sa plus grande valeur.