Comment Vapalape regroupe des millions d'offres en produits uniques

Publié le 22 juillet 20265 min de lecture

Tags:techpipelinedata

Comment Vapalape regroupe des millions d'offres en produits uniques¶

Quand on compare les prix de la vape, le premier défi n'est pas de scraper les boutiques — c'est de savoir que deux offres parlent du même produit. Une boutique vend un « Pod Argus G2 Mini Voopoo », une autre un « Kit Argus G2 Mini+ », une troisième une « cigarette électronique Argus G2 mini plus Voopoo ». Même produit ? Oui. Mais comment un algorithme peut-il en être sûr, à l'échelle de centaines de milliers d'offres ?

Voici comment fonctionne notre pipeline de matching, en deux parties : une première accessible, une seconde plus technique pour les curieux.

Partie 1 — Le pipeline en quatre étapes¶

flowchart LR
    A[Offres brutes<br/>115 000+] --> B[Normalisation]
    B --> C[Blocking & Scoring]
    C --> D[Décision]
    D --> E[Application]
    E --> F[Produits unifiés]

Étape 1 — Normaliser le chaos¶

Chaque boutique nomme les produits à sa façon. Un « Pod Argus G2 Mini + Voopoo » devient « argus g2 mini pod » une fois nettoyé : la marque est extraite, le modèle identifié, les attributs comme le volume ou la nicotine sont isolés. On obtient une empreinte normalisée — une signature stable qui servira de base à toutes les comparaisons.

Étape 2 — Générer des paires candidates¶

Comparer chaque offre à toutes les autres serait trop coûteux — des milliards de paires. On utilise des clés de regroupement (même marque, même empreinte, ou proximité sémantique) pour ne garder que les paires plausibles. On en compare quelques millions au lieu de milliards.

Étape 3 — Scorer et décider¶

Chaque paire candidate reçoit un score entre 0 et 1, calculé en combinant :

La similarité des noms normalisés
La proximité sémantique via des embeddings
Des règles structurelles : même volume ? même taux de nicotine ? même modèle ?

Le score détermine la décision : fusion automatique, rejet, ou review humaine.

Étape 4 — Appliquer et fusionner¶

Les paires validées sont regroupées en clusters : si A = B et B = C, alors A, B et C désignent le même produit. On choisit un produit canonique et on fusionne les doublons. Résultat : un catalogue unifié, prêt à comparer les prix.

flowchart TD
    subgraph "Avant matching"
        A1["Pod Argus G2 Mini Voopoo<br/>(Boutique A)"]
        A2["Kit Argus G2 Mini+<br/>(Boutique B)"]
        A3["Argus G2 Mini plus Voopoo<br/>(Boutique C)"]
    end
    subgraph "Après matching"
        B1["Argus G2 Mini<br/>(Produit canonique)"]
    end
    A1 --> B1
    A2 --> B1
    A3 --> B1

Partie 2 — Sous le capot (pour les curieux)¶

La normalisation : bien plus qu'un simple nettoyage¶

La normalisation ne se contente pas de mettre en minuscule et d'enlever les accents. Elle extrait la marque via un résolveur qui connaît les alias (« ELF » → « Eliquid France »), isole les attributs structurés (volume, nicotine, puissance) du nom, et produit une signature modèle (les tokens contenant un chiffre comme « g2 », « m100 ») qui distingue les variantes d'une même gamme.

L'empreinte finale combine la marque, les tokens significatifs du nom, le volume et la nicotine. Deux offres avec la même empreinte sont le même produit — à coup sûr.

Le scoring : lexical + sémantique + règles¶

Le score combine trois signaux complémentaires :

Signal	Ce qu'il apporte	Exemple
Lexical	Précision sur les tokens du nom	« argus g2 mini » ≈ « argus g2 mini pod »
Sémantique	Rappel sur les synonymes	« pod » ≈ « cigarette electronique pod »
Règles structurelles	Discrimination forte	Même volume ? Même nicotine ? Même signature modèle ?

Une règle importante : une forte similarité sémantique ne suffit jamais à déclencher une fusion automatique. Elle peut promouvoir une paire vers la review humaine, mais l'automatique reste piloté par le lexical et les règles — la précision avant tout.

Les garde-fous¶

Plusieurs mécanismes protègent contre les erreurs :

Catégories incompatibles : un clearomiseur ne sera jamais fusionné avec un e-liquide, même s'ils partagent la même marque
Noms incompatibles : quand un cluster fusionne des produits aux noms vraiment différents (ex. « pod VMate » et « pod Argus »), une garde bloque la fusion — c'est probablement une erreur de rattachement initial

flowchart TD
    subgraph CLUSTER["Un cluster de 3 offres candidates"]
        P1["Offre A : 'pod vmate'"]
        P2["Offre B : 'argus g2 mini'"]
        P3["Offre C : 'argus g2 mini pod'"]
    end
    CLUSTER --> GUARD{"🔍 Garde de similarité<br/>des noms"}
    GUARD -->|"✅ Noms compatibles"| MERGE["Fusion automatique<br/>→ 1 produit canonique"]
    GUARD -->|"🚫 Noms incompatibles"| BLOCK["🚫 Fusion bloquée<br/>→ envoi en review humaine"]

La garde compare les noms normalisés de tous les produits distincts d'un cluster. Si deux produits ont des noms radicalement différents (comme « VMate » et « Argus »), le cluster est bloqué et renvoyé en review humaine plutôt que d'être fusionné incorrectement.

Doublons intra-boutique : une même boutique ne peut pas fournir deux offres pour le même produit canonique

En chiffres¶

Aujourd'hui, le pipeline traite plus de 115 000 offres et génère environ 4 millions de paires candidates. Parmi elles, environ 230 000 sont fusionnées automatiquement, et 1,6 million attendent une review humaine.

Le résultat : des dizaines de milliers de produits unifiés, des prix comparables, et une expérience utilisateur propre.