Cold start en e-commerce : des embeddings à la connaissance du monde des LLM

Par Grégory Le Goff · 2026-08-05

Toute boutique en ligne connaît ce moment: le catalogue est prêt, le site tourne, mais le bloc « vous aimerez aussi » reste vide ou recrache des best-sellers sans rapport avec ce que le visiteur regarde. Ce n'est pas un bug de configuration. C'est un problème structurel connu sous le nom de cold start ou le démarrage à froid, et il touche tous les moteurs de recommandation, quel que soit l'éditeur.

La bonne nouvelle, c'est que ce problème a une histoire, et que les solutions se sont empilées par couches successives. Comprendre ces couches permet de savoir exactement ce qu'on peut attendre, et ne pas attendre, d'un moteur de recommandation dès le premier jour.

Le problème de départ: pas de clics, pas de patterns

La majorité des moteurs de recommandation reposent historiquement sur le filtrage collaboratif: on compare les utilisateurs entre eux à partir de leur comportement (clics, ajouts au panier, achats), et on recommande à quelqu'un ce que des utilisateurs au profil proche du sien ont apprécié.

C'est puissant, mais entièrement dépendant du volume de données comportementales. Sans interactions, il n'y a rien à comparer:

utilisateurs → interactions → profils similaires → recommandations

Une variante a ensuite émergé pour raisons de scalabilité plutôt que conceptuelles: le filtrage item-to-item, popularisé par Amazon dès 2003 [1]. Au lieu de comparer des utilisateurs entre eux, on précalcule hors-ligne les cooccurrences d'achat entre produits d'où la formule bien connue « les clients qui ont acheté X ont aussi acheté Y ». C'est produit-à-produit dans son calcul, mais ça reste, au fond, exactement la même famille: une statistique tirée d'achats passés. Un produit tout juste ajouté au catalogue, avec zéro achat à son actif, n'a toujours aucune cooccurrence à exploiter. L'item-to-item ne sort pas du comportemental, il ne fait que changer l'axe sur lequel la statistique est calculée.

Une nouvelle boutique, un nouveau produit, une collection saisonnière tout juste lancée: dans tous ces cas, ce maillon central c'est à dire les interactions, qu'elles soient comptées par utilisateur ou par produit manque à l'appel. Le moteur reste silencieux, parfois pendant plusieurs semaines, le temps d'accumuler assez de signal. La littérature de recherche en systèmes de recommandation documente ce problème depuis longtemps sous le nom de cold start, qu'il touche un nouvel utilisateur ou un nouvel item [2].

Une autre parade, plus ancienne et plus grossière, a consisté à monter d'un cran de granularité: au lieu de raisonner produit par produit, on raisonne par famille de produits. Des règles génériques sont établies une fois pour toutes tel que « appareils photo → cartes mémoire », «perceuses → mèches» souvent héritées de l'analyse de panier (market basket analysis), une technique de fouille de données popularisée par l'algorithme Apriori [3]. L'avantage: une famille entière de produits, même tout juste ajoutée au catalogue, hérite immédiatement de règles déjà établies pour sa catégorie, sans attendre le moindre historique propre. L'inconvénient: la règle s'applique à l'aveugle, sans vérification de compatibilité au niveau de chaque produit précis, deux pompes de piscine de la même famille peuvent avoir un débit très différent, et la règle générique ne fait pas la différence. Pour compenser le côté générique, et parfois répétitif, de ces recommandations, un peu d'aléa est souvent injecté afin de varier les propositions et donner une impression de diversité (Une préoccupation que la recherche sur la diversité et la sérendipité des systèmes de recommandation documente également [4]).

Brique 1: la similarité par embedding (la vraie rupture avec le comportemental)

La première réponse qui sort réellement de la logique comportementale, qu'elle soit calculée par utilisateur ou par produit a consisté à ne plus regarder ce que les gens font, mais ce que le produit est c'est à dire sa fiche, indépendamment de tout achat ou clic.

Chaque fiche produit (titre, description, catégorie, caractéristiques, parfois l'image) est transformée en un embedding: un vecteur numérique qui capture le sens du produit, une technique popularisée en traitement du langage par des modèles comme Sentence-BERT [5]. Deux produits dont les vecteurs sont proches dans cet espace sont, sémantiquement, proches dans la réalité. Une « montre de plongée étanche 200 m » et une « montre étanche 100 m » se retrouvent naturellement voisines, sans qu'un seul client n'ait eu besoin de cliquer sur l'une ou l'autre.

C'est ce qu'on appelle la recommandation basée contenu:

produits → vecteurs sémantiques → voisins les plus proches → recommandations

L'avantage est immédiat: ça fonctionne dès l'ingestion du catalogue, sans historique. C'est devenu la brique de base de la plupart des moteurs modernes, des géants du secteur aux solutions plus modestes.

Sa limite, en revanche, est structurelle: cette approche trouve des produits similaires, pas des produits complémentaires. Elle sait qu'une perceuse ressemble à une autre perceuse. Elle ne sait pas, en soi, qu'une perceuse appelle des mèches, parce que ce lien n'est pas une question de proximité sémantique entre deux fiches produit, mais une question d'usage: une perceuse est littéralement inopérante sans mèche insérée, ce qui n'a rien à voir avec le fait que deux perceuses se ressemblent sur le papier.

Brique 2: transférer les complémentaires par analogie

Avant d'aller chercher une connaissance générale externe, il existe une astuce intermédiaire, moins coûteuse, qui exploite ce que le catalogue sait déjà de lui-même: si un produit A a un complémentaire connu et validé (parce que la relation existe déjà ailleurs dans le catalogue, ou sur un autre marchand), et qu'un nouveau produit A' est sémantiquement très proche de A, alors le complémentaire de A est un bon candidat de complémentaire pour A'.

Autrement dit, on propage les relations connues le long des voisinages d'embedding plutôt que de les réapprendre depuis zéro pour chaque nouveau produit:

A a pour complémentaire C (relation connue) + A' est similaire à A (brique 1) → C est candidat pour A'

C'est une manière élégante de faire du neuf avec de l'ancien, mais elle a un point aveugle: la similarité sémantique entre A et A' ne garantit pas que A' partage les mêmes contraintes physiques que A. Deux pompes de piscine peuvent avoir un titre et une description presque identiques tout en ayant un débit très différent ; le filtre compatible avec l'une peut être totalement inadapté à l'autre.

Cette technique ne peut donc pas fonctionner sans une couche de vérification de compatibilité: avant de proposer C comme complémentaire de A', il faut vérifier que les caractéristiques critiques (dimensions, débit, capacité, voltage, connecteurs...) de A' sont bien compatibles avec C et pas seulement que A' ressemble à A en surface. Sans ce garde-fou, on hérite aussi bien des bonnes analogies que des mauvaises.

Brique 3: mobiliser la connaissance du monde des LLM

C'est ici qu'une évolution plus récente change la donne. Les grands modèles de langage (LLM) n'ont pas seulement appris à représenter le sens des mots, ils ont, au passage, absorbé une quantité considérable de connaissance générale sur le monde: comment les objets s'utilisent, ce qui va avec quoi, quelles précautions accompagnent quel usage. Des travaux de recherche récents montrent que cette connaissance générale permet aux LLM de produire des recommandations compétitives en situation de démarrage à froid, y compris sans historique d'interactions [6], ce qui a conduit à toute une littérature dédiée à leur usage pour la recommandation cold start [7].

Cette connaissance peut être mobilisée directement, sans attendre qu'elle soit réapprise depuis les clics d'un site en particulier. Un LLM « sait » qu'une perceuse s'accompagne généralement de mèches, d'un support et de lunettes de protection. C'est exactement comme un vendeur expérimenté en magasin de bricolage le saurait, sans avoir eu besoin d'observer les ventes croisées de ce magasin précis.

Concrètement, cette approche permet de construire:

des taxonomies d'intentions d'achat (percer/fixer, se protéger, mesurer avec précision...) reliées entre elles par des liens de compatibilité métier, plutôt qu'appris statistiquement ;
des relations de complémentarité initialisées par du bon sens général, avant même qu'un seul achat croisé n'ait eu lieu sur le site ;
une validation sémantique des paires de produits proposées, pour éviter les associations absurdes qu'une simple proximité vectorielle pourrait produire.

La différence avec les deux briques précédentes est fondamentale: on ne cherche plus seulement « qu'est-ce qui ressemble à ce produit ? » ni « qu'est-ce que le catalogue sait déjà par analogie ? », mais « qu'est-ce qui va logiquement avec ce produit, dans son usage réel, même si rien de comparable n'existe encore dans le catalogue ? ».

Ce que ça change concrètement

En superposant ces trois briques, un moteur de recommandation peut couvrir l'intégralité du parcours cold start:

Jour 0: les embeddings assurent une base de similarité fiable dès l'ingestion du catalogue.
Toujours au jour 0: les relations déjà connues sur des produits proches sont proposées par analogie, sous réserve d'une vérification de compatibilité. C'est le meilleur rapport coût/valeur quand le catalogue contient déjà des cas similaires validés.
Toujours au jour 0, mais en plus riche: la connaissance encyclopédique du LLM ajoute une couche de complémentarité et d'intention d'achat même là où aucune analogie ne suffit, sans attendre le moindre historique.
Avec le temps: les signaux comportementaux réels, une fois disponibles, viennent affiner et corriger ce que ces trois briques avaient initialement proposé, dans une logique hybride, plutôt que de tout reconstruire à zéro.

En résumé

Le cold start n'est pas un problème binaire: « on a des données ou on n'en a pas » mais un problème qui se résout par couches. La similarité par embedding a déjà rendu obsolète l'idée qu'il faille attendre des semaines de trafic pour recommander quoi que ce soit. Le transfert par analogie, bien gardé par une vérification de compatibilité, permet de réutiliser ce que le catalogue sait déjà. La mobilisation de la connaissance générale des LLM va un cran plus loin encore: elle permet de recommander non seulement ce qui ressemble, mais ce qui va avec, dès le premier jour d'existence d'un catalogue.

Reste ensuite la question de la mise en œuvre: c'est un sujet que nous détaillons dans un article dédié, à partir de notre propre implémentation chez RecoKit.

Sources

G. Linden, B. Smith, J. York, Amazon.com Recommendations: Item-to-Item Collaborative Filtering, IEEE Internet Computing, 2003.
J. Gope, S. K. Jain, A survey on solving cold start problem in recommender systems, IEEE ICCCA, 2017.
R. Agrawal, R. Srikant, Fast Algorithms for Mining Association Rules in Large Databases, VLDB, 1994.
M. Kaminskas, D. Bridge, Diversity, Serendipity, Novelty, and Coverage: A Survey and Empirical Analysis of Beyond-Accuracy Objectives in Recommender Systems, ACM TiiS, 2016.
N. Reimers, I. Gurevych, Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks, EMNLP-IJCNLP, 2019.
S. Sanner et al., Large Language Models are Competitive Near Cold-start Recommenders for Language- and Item-based Preferences, arXiv:2307.14225, 2023.
W. Zhang et al., Cold-Start Recommendation towards the Era of Large Language Models (LLMs): A Comprehensive Survey and Roadmap, arXiv:2501.01945, 2025.