Similarité de contenu (synopsis, genre) et popularité réelle — le nombre d'achats déjà réalisés par l'ensemble de vos clients sur chaque produit. Ce n'est donc pas un classement à l'aveugle : il n'y a simplement pas d'historique personnel pour ce visiteur précis.

Le moteur compare le synopsis, le genre et les mots-clés du produit consulté à ceux de tout le catalogue. Plus la barre est pleine, plus le contenu se ressemble ; le badge doré signale un genre identique.

Le niveau est relatif à la meilleure recommandation trouvée pour cette recherche, pas à une échelle absolue — nécessaire car les scores de contenu, de collaboratif et d'hybride ne vivent pas sur la même échelle numérique.

ALS (Alternating Least Squares) est un algorithme de factorisation matricielle : il apprend, à partir des achats/vues de tous les utilisateurs, des profils de goûts latents — sans jamais regarder le contenu des produits. Deux personnes qui achètent les mêmes choses se retrouvent « proches », même si leurs achats semblent variés à l'œil nu.

Deux utilisateurs, deux historiques d'achats. Le moteur ne connaît rien du contenu des produits — il repère seulement que les mêmes titres reviennent chez les deux, et en déduit un goût commun.

Mélange les deux signaux avec un poids réglable. Déplacez le curseur pour voir le classement se réorganiser en direct entre similarité de contenu et goûts collaboratifs.

Cette page résume l'architecture qui fait tourner les 6 onglets précédents et le suivi de modèle qui suit celle-ci : comment le moteur est découplé de n'importe quelle interface, comment chaque client est isolé des autres, et quels sont les leviers concrets pour l'améliorer dans le temps.

Cette démo en est la preuve : la page que vous utilisez ne parle jamais directement au code Python — elle appelle uniquement le SDK JavaScript/TypeScript, qui appelle l'API par HTTP. N'importe quel autre front (site e-commerce, application mobile, outil interne) peut brancher le même SDK, ou l'un des deux autres (PHP, Python), sans jamais toucher au moteur lui-même.

L'intérêt commercial de cette séparation : on peut refaire entièrement l'interface (ou en brancher une nouvelle, dans un autre langage) sans toucher au moteur ; on peut faire évoluer le moteur (nouvel algorithme, nouveau modèle) sans casser les intégrations existantes, tant que le contrat de l'API ne change pas.

Une seule API et une seule infrastructure servent tous les clients, mais rien n'est partagé entre eux : chaque client a ses propres lignes en base (scoped par client_id), son propre modèle ALS entraîné sur ses seules données (model/client_{id}/*.npz), et ses propres embeddings sémantiques (colonne vector dans PostgreSQL via pgvector, filtrée par client_id) — pas un index vectoriel séparé à gérer par client.

Le cycle est le même que pour n'importe quel moteur collaboratif : plus les clients de votre client achètent/consultent de produits, plus le modèle a de signal pour apprendre. La différence ici : un nouveau modèle n'est jamais mis en production seul sur la base de son entraînement — il est d'abord mesuré, comparé à la version actuellement active, et rejeté automatiquement s'il est moins bon.

↺ Déclenchement automatique dès que 50 nouvelles interactions s'accumulent depuis le dernier entraînement — plus besoin d'appeler /generateModel à la main.

Chaque réentraînement est mesuré avant d'être mis en production : une nouvelle version n'est jamais servie si elle est moins bonne que celle déjà active. Voici l'historique réel des versions du modèle collaboratif (films), avec leur score de précision et leurs hyperparamètres — pas une maquette, ces données viennent de la même API que le reste de cette démo.