Big Data pour les systèmes de recommandation : architecture, pipelines et métriques

Sur le papier, un recommender apprend des préférences et classe des items. En production, la donnée (tracking, catalogue, pipelines) fait la différence.

Le « Big Data » des recommandations, c’est l’ingénierie : flux massifs, catalogue mouvant, multi-canaux et latence serrée. Voici les choix data pour une personnalisation fiable et mesurable.

{{IMG_1}}

Pourquoi le Big Data est la partie la plus difficile des systèmes de recommandation

Un recommender est une boucle : exposition → réaction → signal d’entraînement. Le défi vient d’une chaîne data intensive et couplée au produit :

• Volume : les événements (impressions, clics, achats) s’accumulent très vite.
• Vélocité : la pertinence dépend de la récence (intention de session, tendances, stock).
• Variété : logs comportementaux + métadonnées catalogue + attributs utilisateur/compte + règles métier.
• Véracité : IDs incohérents, champs manquants, bots, changements de tracking : l’entraînement se dégrade sans alerte.

Piège : biais d’exposition. Sans impressions, impossible de savoir ce qui a été vu mais ignoré. Elles fondent les labels et l’évaluation offline.

Quand la base data est faible, les symptômes sont récurrents :

• Les métriques offline sont bonnes, mais les tests A/B ne bougent pas les KPI.
• Le réentraînement est lent/fragile, car les datasets ne sont pas reproductibles.
• Drift entre entraînement et serving (features différentes en production).
• La latence impose un caching lourd, ce qui dégrade la fraîcheur.
• Cold start persistant, faute de métadonnées item/utilisateur.

La sortie se fait via des datasets fiables et corrects dans le temps, avec ownership, SLA et monitoring.

Sources de données et design des événements : quoi collecter (et quoi éviter)

Les recommenders performants s’appuient sur quelques domaines à fort signal, capturés de façon cohérente :

• Événements d’exposition : impressions, recommandations envoyées, emails, push (avec position et contexte).
• Événements d’engagement : clics, vues, plays, temps passé, scroll, « enregistrer », « panier », « masquer ».
• Événements de résultat : achats, abonnements, renouvellements, leads, tickets résolus (selon votre produit).
• Données catalogue/contenu : titres, catégories, attributs, prix, disponibilité, langue, permissions, statut.
• Contexte utilisateur/compte : segment, offre, secteur, rôle, locale, consentement (minimiser la PII).
• Contraintes opérationnelles : stock, marge, conformité, droits contractuels, contraintes de SLA.

Premier levier : une taxonomie d’événements standardisée (schéma versionné, docs, change management). Un événement « minimum viable » inclut :

• Identifiants : ID utilisateur/compte (stable ou pseudonyme), ID item, ID session.
• Temps : timestamp UTC + timestamp d’ingestion (retards).
• Contexte : surface (home, search, email), module, position, page/écran.
• Trace : request ID, recommendation ID, modèle/version, bucket d’expérience.
• Issue : cliqué/vu/acheté + feedback négatif (masquer, dislike, unsubscribe).

À éviter : logguer des données personnelles brutes. IDs pseudonymisés, payloads légers, rétention cadrée. En B2B, priorité aux permissions compte : ne jamais exposer du contenu restreint.

Patterns d’architecture : batch, streaming et stack de recommandation à deux vitesses

Une architecture « deux vitesses » domine : batch pour le lourd, online pour servir vite, sans dériver les coûts.

Chez DataSqueeze, nous industrialisons des pipelines de data engineering et big data pour garder la recommandation cohérente, du tracking au serving.

Architecture de référence :

• Ingestion : événements web/mobile/backend vers un bus de streaming ou un log (plus backfill batch).
• Stockage : événements bruts en partitions immuables, puis couches « clean » et « prêtes métier » (lakehouse/warehouse).
• Features & training : agrégats point-in-time, séquences, embeddings.
• Génération de candidats : similarité item-item, embeddings, candidats par segment.
• Ranking online : récupérer candidats + contexte récent, scorer et trier sous contrainte de latence.
• Serving & caching : cache de candidats stables, store clé-valeur pour features, fallbacks.
• Expérimentation & monitoring : tracer l’exposition, mesurer l’impact, détecter la dérive.

Le batch construit les bases, l’online ajuste en temps réel. Ainsi, l’online reste léger quand l’historique grossit.

{{IMG_2}}

Feature engineering à l’échelle : des événements bruts aux datasets prêts pour l’entraînement

Les modèles apprennent via des features. Risque majeur : la fuite de données, quand une info future se glisse dans l’entraînement.

Règle : point-in-time correctness. Les features d’une impression n’utilisent que le passé.

Exemples de features :

• Utilisateur/compte : fréquence, affinités catégories, récence pondérée, gammes de prix.
• Item : popularité (fenêtres glissantes), conversion par segment, fraîcheur, disponibilité.
• Contexte : device, locale, heure, canal, requête ou type de page.
• Séquences : derniers N items/catégories, embeddings de session.
• Embeddings : signaux collaboratifs ou contenu (texte/image) pour le retrieval.

Le calcul est « join-heavy » : un lakehouse raw/clean/curated facilite backfills et cohérence ; ce guide d’implémentation d’un data lake sert de base.

Pseudo-code : labels à partir des expositions, puis features « as-of ».

# Pseudo-code (conceptual)
impressions = read_events("impression")
clicks = read_events("click")

# Label impressions by whether a click happened within a window
labeled = impressions.left_join(
  clicks,
  on=["user_id", "item_id", "impression_id"],
  within="24h"
)
labeled["y_click"] = labeled["click_ts"].not_null()

# Fetch features as they were at impression time (point-in-time)
features = feature_store.offline_fetch(
  entities=labeled[["user_id", "item_id"]],
  as_of=labeled["impression_ts"]
)

train_set = labeled.join(features)

Pour les coûts : agrégats lourds en incrémental, temps réel réservé aux features de session.

Choix de modélisation : ce qui façonne votre charge data

Le modèle dicte la charge : logs, training set et compute. La plupart des stacks combinent :

• Génération de candidats (retrieval) : réduire le catalogue à quelques centaines/milliers d’items.
• Ranking : scorer avec plus de contexte et de contraintes, puis ordonner.

Pour (re)construire, le développement de systèmes de recommandation commence par choisir l’étage le plus rentable selon vos données.

Impacts data typiques :

• Similarité item-item : sessions/cooccurrences propres ; tolère des IDs utilisateur rares.
• Factorisation / two-tower : gros historiques + negative sampling maîtrisé.
• Rankers GBDT : features stables + prévention stricte du leakage ; très bons en tabulaire.
• Deep rankers : plus de données, cohérence forte des features, serving plus exigeant.
• Cold start hybride : métadonnées item + embeddings de contenu pour compenser la rareté.

En B2B, le niveau compte/segment est souvent plus robuste que l’individuel lorsque l’activité est clairsemée.

Mesurer l’impact et garder le système en bonne santé en production

La « précision » ne suffit pas : reliez offline → online et suivez la santé du pipeline.

Métriques à suivre :

• Offline : Precision@K, Recall@K, NDCG, MAP (si possible sur la base des impressions).
• Catalogue : couverture, diversité, nouveauté, concentration.
• Business online : CTR, conversion, revenu/session, rétention, qualité des leads, time-to-resolution.
• Garde-fous : latence (p95), erreurs, bounce rate, désabonnements/masquages, violations.

Tests A/B : référence si exposition tracée et assignation stable. Déploiement progressif + fallbacks (popularité, éditorial, catégories) sur les surfaces critiques.

En exploitation, définissez des SLO et surveillez :

• Fraîcheur : arrivée des événements et mises à jour d’agrégats.
• Schéma & volume : champs manquants, changements de tracking, bots.
• Skew : cohérence entre définitions offline et features online.
• Dérive : saisonnalité, refresh du catalogue, nouveaux segments.
• Coûts : refresh embeddings, jointures, appels de ranking.

Gouvernance dès le départ : minimisation, rétention, accès et auditabilité.

{{IMG_3}}

FAQ : Big Data et systèmes de recommandation

Faut-il du streaming dès le premier jour ? Souvent non : démarrez en batch, puis streamez seulement pour session, stock et contenus volatils.

Quel historique conserver pour l’entraînement ? Entraîner sur une fenêtre récente, garder plus long pour certains agrégats, avec décroissance temporelle.

Faut-il une base de données vectorielle ? Oui si le retrieval par embeddings est central. Sinon, tables item-to-item ou règles suffisent : gardez la voie la plus simple (latence/fraîcheur).

Comment éviter la fuite de données en pratique ? Labels sur l’exposition, features « as-of », jointures temporelles et contrôles automatiques.

Que faire cette semaine : une checklist d’implémentation pragmatique

Pour avancer vite, attaquez les quelques étapes qui débloquent l’itération :

• Choisir une surface et un objectif : par exemple « augmenter les clics qualifiés sur le module home », avec des garde-fous clairs.
• Standardiser le tracking : implémenter le logging des impressions avec placement, position et version de modèle ; valider par échantillonnage.
• Créer un dataset reproductible : couches raw/clean/curated, backfills et définitions de features versionnées.
• Livrer une baseline : popularité + similarité item-item simple, avec fallbacks sûrs et contraintes explicites.
• Ajouter un composant d’apprentissage : un ranker léger sur un petit set de features bien gouverné.
• Définir l’évaluation et le rollout : métriques offline pour itérer, puis plan de test A/B avec logging d’exposition.
• Mettre en place le monitoring : fraîcheur, drift de schéma, latence et KPI business liés au recommender.

Une fois ces bases en place, le système devient prévisible : refresh régulier, latence stable et gains attribuables.

Si vous voulez un audit data orienté implémentation, un blueprint d’architecture et un PoC cadré pour votre stack de recommandation, contactez-nous.