Data Engineering 27 janvier 2026 15 min de lecture

Systèmes de recommandation : quelle architecture de base de données choisir ?

Comparatif Graph DB vs Vector DB pour les systèmes de recommandation. Retour d'expérience avec PostgreSQL et pgvector sur un agrégateur de mode éco-responsable.

RecommandationpgvectorPostgreSQLMachine LearningNLP

Nathan ML OPS

Introduction

Vos utilisateurs parcourent votre catalogue sans rien trouver. Ils scrollent, cliquent, repartent. Pendant ce temps, vos concurrents affichent "Les clients ayant acheté X ont aussi aimé Y" et convertissent. Les systèmes de recommandation ne sont plus un luxe : chez les leaders du e-commerce, ils génèrent en moyenne 24% des commandes. Netflix estime que 80% du contenu visionné est découvert via ses recommandations.

Mais derrière ces statistiques se cache une question technique rarement abordée : comment stocker et interroger les données qui alimentent ces recommandations ? Bases de données graphe, bases vectorielles, hybrides — chaque approche a ses avantages et ses limites.

Dans cet article, nous partons d'un cas concret — Tossée, un agrégateur de mode éco-responsable — pour explorer les architectures de bases de données derrière un système de recommandation. Le défi : recommander des alternatives écologiques à partir de données textuelles mal structurées, issues de dizaines de vendeurs différents. Nous avons commencé par une approche graphe, avant d'évoluer vers le vectoriel. Mais pourquoi pas une approche hybride ? Que font les grandes plateformes, et qu'en retenir à notre échelle ?

Cas d'usage

Un système de recommandation devient pertinent quand plusieurs de ces signaux apparaissent :

Votre catalogue dépasse quelques centaines de références. En dessous, la navigation manuelle suffit. Au-delà, vos utilisateurs se perdent.
Votre taux de conversion stagne malgré du trafic. Les visiteurs viennent mais ne trouvent pas ce qu'ils cherchent — ou ne savent pas qu'ils le cherchent.
Vos données produits sont riches. Descriptions détaillées, attributs structurés, catégories multiples : plus vous avez de matière, plus les recommandations seront pertinentes.
Vous avez de l'historique utilisateur. Achats, clics, paniers abandonnés — ces interactions alimentent le filtrage collaboratif.
Vos équipes passent du temps à "pousser" manuellement des produits. Un système automatisé libère ce temps et personnalise à l'échelle.

Sur le projet Tossée, plusieurs de ces signaux étaient réunis : un catalogue de dizaines de milliers de références issues de multiples vendeurs, des données produits riches mais mal structurées, et un besoin de recommandation automatisée pour orienter les consommateurs vers des alternatives éco-responsables.

Pourquoi le choix de la base de données compte

Le problème de scalabilité

Un système de recommandation peut fonctionner de deux manières. La première : précalculer toutes les recommandations à l'avance, les stocker, et les servir directement. Simple, rapide à la lecture, mais coûteux à maintenir. Chaque nouveau produit ou nouvelle interaction utilisateur nécessite un recalcul.

La seconde : calculer à la volée. L'utilisateur arrive, le système analyse son profil en temps réel, interroge la base, et renvoie des suggestions personnalisées. Plus flexible, mais les performances dépendent directement de la capacité de la base de données à répondre en quelques millisecondes.

Le choix de l'architecture de stockage détermine laquelle de ces approches est réaliste pour votre cas d'usage.

Le problème de maintenance

Un catalogue e-commerce évolue constamment. Nouveaux produits, articles retirés, changements de prix, mises à jour des descriptions. Le système de recommandation doit intégrer ces changements sans nécessiter une reconstruction complète.

Certaines architectures gèrent bien l'ajout incrémental. D'autres nécessitent un recalcul global à chaque modification significative. Sur un catalogue de 50 000 références, cette différence peut représenter des heures de traitement quotidien — ou quelques secondes.

Content-based vs Collaborative filtering

Avant de parler de bases de données, rappelons les deux grandes familles d'algorithmes de recommandation.

Le filtrage basé sur le contenu (content-based) analyse les caractéristiques des produits : catégorie, marque, description, attributs. Si vous avez acheté une chemise en lin bleu, le système vous propose d'autres chemises en lin ou d'autres vêtements bleus.

Le filtrage collaboratif analyse les comportements des utilisateurs similaires. Si les utilisateurs qui ont acheté les mêmes articles que vous ont aussi acheté un pantalon spécifique, le système vous le suggère — même si ce pantalon n'a aucun attribut commun avec vos achats précédents.

Ces deux approches ont des implications différentes sur le stockage. Le content-based manipule des vecteurs de caractéristiques. Le collaboratif manipule des relations entre entités (utilisateurs, produits, interactions). Le choix de la base de données dépend de l'approche privilégiée — ou de la capacité à combiner les deux.

Dans le cas de Tossée, les données étaient principalement textuelles (descriptions produits, matériaux, catégories) et l'historique utilisateur quasi inexistant au lancement. Cela orientait naturellement vers une approche content-based — avec des conséquences directes sur le choix de stockage.

Les deux grandes familles de stockage

Bases de données graphe

Une base de données graphe stocke l'information sous forme de nœuds et d'arêtes. Les nœuds représentent des entités (utilisateurs, produits, catégories). Les arêtes représentent les relations entre ces entités (a acheté, appartient à, est similaire à).

Cette structure excelle pour le filtrage collaboratif. Trouver "les produits achetés par des utilisateurs similaires" se traduit par une traversée de graphe : partir de l'utilisateur, suivre ses achats, remonter aux autres acheteurs de ces produits, suivre leurs autres achats. C'est exactement ce pour quoi les bases graphe sont optimisées.

Avantages : les recommandations sont explicables. Vous pouvez dire "Recommandé parce que des clients comme vous ont aussi acheté cet article". Les traversées multi-hop permettent des recommandations sophistiquées (amis d'amis, produits complémentaires de produits similaires).

Limites : les relations doivent être calculées et stockées explicitement. Ajouter un nouveau produit au catalogue nécessite de calculer ses relations avec tous les produits existants. Sur un catalogue volumineux, ce recalcul peut devenir prohibitif. C'est exactement le problème que nous avons rencontré sur Tossée : avec des dizaines de milliers de références et des ajouts réguliers, le recalcul des relations devenait un goulet d'étranglement. L'approche graphe avait un atout : les relations explicites permettaient d'auditer les recommandations — comprendre pourquoi tel produit était suggéré plutôt qu'un autre. Mais nous maintenions deux bases en parallèle (graphe pour les relations, documentaire pour les produits), une source constante de bugs et de complexité opérationnelle.

Bases de données vectorielles

Une base de données vectorielle stocke chaque entité comme un vecteur dans un espace à haute dimension. Un produit devient un point dans un espace à 768 dimensions (typiquement). La similarité entre produits se mesure par la distance entre leurs vecteurs — généralement la similarité cosinus.

Pour recommander des produits similaires, on calcule le vecteur du produit consulté, puis on cherche les k vecteurs les plus proches (k-NN, k-nearest neighbors). Les algorithmes d'indexation comme HNSW (Hierarchical Navigable Small World) permettent cette recherche en quelques millisecondes, même sur des millions de vecteurs.

Avantages : le calcul se fait à la volée. Un nouveau produit est immédiatement disponible pour la recommandation dès que son vecteur est calculé — pas besoin de recalculer ses relations avec tout le catalogue. Les embeddings capturent la sémantique : deux produits aux descriptions similaires auront des vecteurs proches, même sans relation explicite.

Limites : l'explicabilité est plus difficile. Pourquoi deux vecteurs sont-ils proches ? L'espace de 768 dimensions n'est pas interprétable par un humain. Les recommandations basées sur les relations (achetés ensemble, vus ensemble) nécessitent une approche complémentaire.

Pour Tossée, c'est cette approche vectorielle qui s'est imposée. L'ajout de produits était très régulier, et le modèle graphe imposait un recalcul à chaque ajout. Avec l'approche vectorielle, un nouveau produit est immédiatement comparable aux autres dès que son embedding est calculé — sans recalcul global.

En pratique : pgvector et PostgreSQL

Dans la famille vectorielle, une solution se distingue par sa simplicité d'adoption.

pgvector est une extension PostgreSQL qui ajoute le support des vecteurs et de la recherche de similarité. Version 0.8.1 au moment de cet article, avec plus de 19 000 étoiles sur GitHub — un signe de maturité et d'adoption.

Pourquoi pgvector plutôt qu'une base vectorielle dédiée comme Pinecone ou Weaviate ? La réponse tient en un mot : simplicité. Si votre infrastructure repose déjà sur PostgreSQL, pgvector s'ajoute comme une extension. Pas de nouvelle base à opérer, pas de synchronisation entre systèmes, pas de nouvelle technologie à apprendre. Et un avantage souvent négligé : moins de services à faire tourner, c'est moins de ressources consommées.

Voici à quoi ressemble une requête de recommandation avec pgvector :

SELECT id, nom, description
FROM produits
ORDER BY embedding <=> '[0.12, -0.34, 0.56, ...]'::vector
LIMIT 10;

L'opérateur <=> calcule la distance cosinus. La requête renvoie les 10 produits dont les embeddings sont les plus proches du vecteur donné. Avec un index HNSW, cette requête s'exécute en quelques millisecondes sur des centaines de milliers de produits.

C'est la solution que nous avons retenue pour Tossée. Pour générer les embeddings, nous utilisons CamemBERT — plus précisément sentence-camembert-large (336 millions de paramètres), un modèle entraîné sur du texte français et optimisé pour la similarité sémantique. Le choix d'un modèle français n'est pas anodin : les descriptions de vêtements contiennent du vocabulaire spécifique (jersey, viscose, maille côtelée) qu'un modèle multilingue généraliste capturait mal.

Le résultat : deux produits décrits comme « t-shirt bleu marine en coton bio » et « haut bleu en coton biologique » ont des embeddings très proches, sans avoir besoin de définir explicitement cette relation. Un nouveau produit est disponible pour la recommandation en quelques secondes — calcul de l'embedding, insertion dans PostgreSQL, c'est tout.

En pratique, comparer un vecteur à l'ensemble du catalogue n'est pas toujours nécessaire. Sur Tossée, nous appliquons un préfiltrage avant la recherche vectorielle : filtrer par genre, par couleur dominante ou par catégorie de vêtement réduit considérablement le nombre de comparaisons. La requête SQL combine alors un WHERE classique avec l'opérateur de distance vectorielle — pgvector gère naturellement cette combinaison.

Et un bénéfice collatéral : en consolidant tout dans PostgreSQL et en calculant les embeddings localement, nous évitons les allers-retours réseau vers des APIs tierces. Pour une plateforme dont la mission est de réduire l'impact environnemental, moins d'infrastructure signifie aussi moins d'énergie consommée.

Au-delà du binaire : les approches hybrides

En réalité, graphe et vecteurs ne sont pas les seules options. Entre ces deux familles, toute une palette d'approches hybrides existe.

Une architecture hybride combine les deux paradigmes : le graphe capture les relations explicites (achats, catégories, liens entre utilisateurs), les vecteurs capturent la similarité sémantique (descriptions, attributs textuels).

Concrètement, cela peut prendre plusieurs formes. La plus simple : utiliser le graphe pour le filtrage collaboratif ("les utilisateurs comme vous ont aimé") et les vecteurs pour le content-based ("produits similaires à celui-ci"). Une approche plus sophistiquée enrichit les embeddings avec des informations issues du graphe — c'est le principe des Graph Neural Networks (GNN), où la représentation vectorielle d'un nœud intègre les caractéristiques de ses voisins.

L'approche GraphRAG pousse cette logique plus loin en combinant graphes de connaissances, recherche vectorielle et modèles de langage. Le graphe structure l'information, les embeddings permettent la recherche sémantique, et le LLM génère des réponses contextualisées.

Ces architectures offrent le meilleur des deux mondes — au prix d'une complexité accrue. Elles se justifient quand les données sont riches et hétérogènes, ou quand les exigences de qualité sont très élevées. Pour Tossée, nous n'avions pas besoin de cette complexité — mais ces principes hybrides inspirent la façon dont nous concevons nos systèmes : commencer simple, garder la possibilité d'enrichir l'architecture si le besoin évolue.

Ce que font les géants

Les sections précédentes présentent graphe, vecteurs et approches hybrides comme des options distinctes. Dans la pratique, les grandes plateformes ne se limitent pas à un paradigme : elles construisent des systèmes complets qui combinent plusieurs approches, alimentés par des volumes de données et des équipes hors norme. Un tour d'horizon de ces architectures permet de comprendre vers où converge le domaine — et pourquoi ces solutions restent inaccessibles pour la plupart des projets.

Netflix a présenté lors de son workshop PRS 2025 son architecture "Hydra" : un système de multi-task learning qui consolide les différents modèles de ranking en un seul modèle partagé. L'objectif : simplifier une infrastructure devenue trop complexe, où chaque "row" de la homepage avait son propre pipeline. Netflix développe également un Foundation Model central qui apprend les préférences utilisateur et les caractéristiques des contenus à partir de toutes les données disponibles — une approche qui combine filtrage collaboratif et content-based à une échelle massive, exactement l'hybride décrit plus haut, mais avec des ressources sans commune mesure.

Spotify a publié à RecSys 2025 plusieurs avancées significatives. Leur système AudioBoost utilise des requêtes synthétiques générées par LLM pour résoudre le problème du cold-start sur les audiobooks — un problème typiquement content-based, résolu ici par la génération vectorielle. Leur recherche Text2Tracks (avril 2025) explore l'utilisation de modèles génératifs pour les recommandations basées sur des prompts en langage naturel.

La tendance 2025-2026 est à la convergence. Microsoft Research a fait évoluer GraphRAG avec LazyGraphRAG (juin 2025), une approche qui réduit les coûts d'indexation de 99,9% par rapport à GraphRAG tout en maintenant une qualité comparable. Le principe : combiner recherche best-first et breadth-first de manière itérative, en différant l'utilisation du LLM pour maximiser l'efficacité.

Ces architectures sont impressionnantes — et disproportionnées pour la plupart des projets. Mais elles sont une source d'inspiration : les principes sous-jacents (combiner plusieurs signaux, itérer sur la qualité des recommandations, simplifier l'infrastructure) s'appliquent à des échelles plus modestes. Sur Tossée, nous avons retenu cette logique de simplification progressive plutôt que de sophistication maximale.

Bilan : graphe vs vectoriel

Voici ce que nous avons observé concrètement sur le projet Tossée :

Critère	Base graphe	Base vectorielle (pgvector)
Similarité sémantique	Faible (relations explicites uniquement)	Forte (embeddings capturent le sens)
Explicabilité	Excellente (relations nommées)	Limitée (distance vectorielle)
Ajout de produits	Recalcul nécessaire	Instantané
Maintenance	Complexe (sync multi-bases)	Simple (une seule base)
Stack technique	Base graphe + base documentaire	PostgreSQL seul

La perte de traçabilité était un compromis accepté. Avec le graphe, les relations explicites facilitaient l'audit des recommandations. Avec les vecteurs, l'audit passe par l'analyse des distances et des attributs communs — moins immédiat, mais suffisant pour nos besoins.

Guide de décision

Quelle architecture choisir pour votre projet ? Voici nos recommandations basées sur les cas d'usage courants.

Choisir une base graphe quand...

Les relations explicites sont au cœur du métier. Réseau social (amis d'amis), système de parrainage, arbres de catégories complexes.
L'explicabilité est une exigence réglementaire. Certains secteurs (finance, santé) imposent de pouvoir expliquer pourquoi une recommandation a été faite. Les bases graphe excellent dans ce domaine.
Les traversées multi-hop sont fréquentes. "Produits achetés par des clients qui ont aussi acheté ce que j'ai acheté" — ce type de requête est naturel en graphe, complexe en vectoriel.

Choisir une base vectorielle quand...

Les données sont principalement textuelles. Descriptions de produits, articles, contenus éditoriaux. Les embeddings capturent la sémantique sans effort de structuration.
Le catalogue évolue fréquemment. E-commerce avec ajouts quotidiens, marketplace, catalogue de contenus. L'ajout instantané est un avantage décisif.
Vous utilisez déjà PostgreSQL. pgvector s'ajoute sans révolutionner votre stack. Pas de nouvelle base à opérer, pas de compétences à acquérir.
Le budget est contraint. Une seule base à maintenir, moins de complexité opérationnelle, moins de coûts d'infrastructure.

Envisager une approche hybride quand...

Les deux types de données coexistent. Relations utilisateur-produit (graphe) + similarité sémantique entre produits (vecteurs).
Vous intégrez un LLM. L'approche GraphRAG combine graphes de connaissances et recherche vectorielle pour alimenter des modèles de langage.
Les exigences évoluent. Commencer simple (vectoriel), enrichir avec des relations explicites si le besoin se confirme.

Conclusion

Le choix entre base graphe et base vectorielle n'est pas un débat théorique. C'est une décision d'architecture qui impacte la maintenabilité, les performances et les coûts de votre système de recommandation.

Notre expérience sur le projet Tossée nous a appris que la simplicité opérationnelle compte autant que les performances brutes. Une architecture qu'on sait maintenir vaut mieux qu'une architecture optimale qu'on peine à opérer.

pgvector et PostgreSQL ne sont pas la réponse à tous les cas d'usage. Mais pour un système de recommandation content-based sur des données textuelles, avec un catalogue qui évolue fréquemment, c'est un choix pragmatique et éprouvé.

Besoin d'aide pour votre système de recommandation ? Contactez nos experts pour discuter de votre projet.