Mise à l'échelle du commerce électronique : comment les pipelines pilotés par l'IA maintiennent la cohérence des attributs produits

Dans le commerce électronique, de grands défis techniques tels que les requêtes de recherche distribuées, la gestion en temps réel des stocks et les systèmes de recommandation sont souvent discutés. Mais dans les coulisses se cache un problème tenace et systématique qui préoccupe les commerçants du monde entier : la gestion et la normalisation des valeurs d’attributs produits. Ces valeurs constituent la base de la découverte de produits. Elles influencent directement les filtres, les fonctions de comparaison, le classement dans la recherche et la logique de recommandation. Dans les catalogues réels, ces valeurs sont cependant rarement cohérentes. On trouve fréquemment des doublons, des erreurs de format ou des ambiguïtés sémantiques.

Un exemple simple illustre l’ampleur du problème : pour une indication de taille, on pourrait avoir côte à côte “XL”, “Small”, “12cm”, “Large”, “M” et “S”. Pour les couleurs, des valeurs comme “RAL 3020”, “Crimson”, “Red” et “Dark Red” se mélangent – des standards comme RAL 3020 et des descriptions libres se confondent de manière incontrôlée. En multipliant ces incohérences sur plusieurs millions de SKU, la profondeur du problème devient évidente. Les filtres deviennent peu fiables, les moteurs de recherche perdent en précision, le nettoyage manuel des données devient une tâche sans fin, et les clients vivent une expérience frustrante de découverte de produits.

La stratégie clé : intelligence avec des garde-fous

Une solution purement boîte noire d’IA n’était pas envisageable. De tels systèmes sont difficiles à comprendre, à déboguer et à maîtriser avec des millions de SKU. L’objectif était plutôt une pipeline prévisible, explicable et contrôlable par l’humain – une IA qui agit intelligemment sans perdre le contrôle.

La réponse résidait dans une architecture hybride, combinant une intelligence contextuelle basée sur des LLM avec des règles déterministes et des contrôles humains. Le système devait répondre à trois critères :

• Traçabilité des décisions
• Prévisibilité des processus
• Possibilité d’intervention humaine sur des données critiques

Traitement hors ligne plutôt que pipelines en temps réel

Une étape architecturale décisive fut le choix de jobs en arrière-plan hors ligne plutôt que de pipelines en temps réel. Cela peut sembler un recul, mais c’est stratégiquement judicieux :

Les systèmes en temps réel entraînent des latences imprévisibles, des dépendances fragiles, des pics de calcul coûteux et une vulnérabilité accrue. Les jobs hors ligne offrent quant à eux :

• Efficacité de traitement : de grandes quantités de données traitées sans charger le système en direct
• Robustesse : les erreurs de traitement n’affectent jamais le trafic client
• Optimisation des coûts : les calculs peuvent être planifiés en périodes creuses
• Isolation : la latence des LLM n’impacte pas la performance des pages produits
• Prévisibilité : les mises à jour sont atomiques et reproductibles

Avec des millions d’entrées produits, cette déconnexion entre la partie client et le traitement des données est indispensable.

Nettoyage des données comme fondation

Avant l’utilisation de l’IA, une étape essentielle de prétraitement éliminait le bruit. Le modèle ne recevait que des entrées propres et claires :

• Normalisation des espaces blancs (espaces en début et fin)
• Suppression des valeurs vides
• Élimination des doublons
• Simplification du contexte catégoriel (transformation des breadcrumbs en chaînes structurées)

Cette étape apparemment simple améliorait considérablement la précision du modèle linguistique. Le principe reste universel : avec cette quantité de données, même de petites erreurs d’entrée peuvent entraîner une cascade de problèmes par la suite.

Traitement contextuel avec LLM

Le modèle linguistique ne faisait pas de tri mécanique. Avec suffisamment de contexte, il pouvait appliquer un raisonnement sémantique :

Le modèle recevait :

• des valeurs d’attribut nettoyées
• des métadonnées catégorielles (ex. “Électroportatif”, “Vêtements”, “Matériel”)
• des classifications d’attributs

Avec ce contexte, le modèle comprenait :

• que “Tension” dans les outils électriques devait être triée numériquement
• que “Taille” pour les vêtements suivait une progression établie (S, M, L, XL)
• que “Couleur” dans certaines catégories respectait des standards comme RAL 3020
• que “Matériau” possédait des hiérarchies sémantiques

Le modèle renvoyait :

• une liste ordonnée de valeurs
• des descriptions d’attributs affinées
• une classification : triable de façon déterministe ou contextuelle

Cela permettait à la pipeline de gérer différents types d’attributs de manière flexible, sans coder de règles fixes pour chaque catégorie.

Logique déterministe de secours

Tous les attributs ne nécessitaient pas d’intelligence IA. Les plages de valeurs numériques, les unités de mesure et les quantités simples bénéficiaient de :

• traitement plus rapide
• prévisibilité garantie
• coûts plus faibles
• élimination de l’ambiguïté

La pipeline détectait automatiquement ces cas et appliquait une logique de tri déterministe. Le système restait efficace et évitait des appels inutiles à LLM.

Contrôle humain via systèmes de tagging

Pour les attributs critiques, les commerçants devaient garder le contrôle final. Chaque catégorie pouvait être taguée :

• LLM_SORT : le modèle décide de l’ordre
• MANUAL_SORT : le partenaire définit explicitement la séquence

Ce système dual faisait ses preuves : l’IA automatisait la routine, l’humain conservait le pouvoir. Cela instaurait la confiance et permettait aux commerçants de surcharger les décisions du modèle si nécessaire, sans interrompre la pipeline.

Persistance dans une base de données centralisée

Tous les résultats étaient directement stockés dans MongoDB, ce qui simplifiait et maintenait l’architecture :

MongoDB servait de stockage opérationnel pour :

• les valeurs d’attribut triées
• les noms d’attribut affinés
• les tags de tri spécifiques à la catégorie
• les métadonnées de champs de tri produits

Cela facilitait la vérification, la surcharge ciblée, la retraitement des catégories et la synchronisation avec des systèmes externes.

Intégration avec l’infrastructure de recherche

Après normalisation, les valeurs alimentaient deux systèmes de recherche :

• Elasticsearch : pour le filtrage par mots-clés et la recherche par facettes
• Vespa : pour la recherche sémantique et la correspondance par vecteurs

Cette dualité garantissait :

• que les filtres s’affichaient dans un ordre logique attendu
• que les pages produits montraient des attributs cohérents
• que les moteurs de recherche classaient plus précisément
• que l’expérience client était plus intuitive

Le niveau de recherche est là où la cohérence des attributs est la plus visible et la plus précieuse pour le business.

Résultats concrets de la transformation

La pipeline transformait des valeurs brutes chaotiques en sorties structurées :

Particulièrement pour les attributs de couleur, la contextualisation a montré toute sa valeur : le système a reconnu que RAL 3020 est une norme de couleur et l’a intégré de manière cohérente entre des valeurs sémantiquement proches.

Vue d’ensemble de l’architecture du système

La pipeline modulaire orchestrée les étapes suivantes :

1. Extraction des données produits du système PIM (Product Information Management)
2. Isolation des valeurs d’attributs et du contexte catégoriel via le job d’extraction
3. Envoi des données nettoyées au service de tri IA
4. Écriture des documents produits mis à jour dans MongoDB
5. Le job de synchronisation sortante met à jour le système PIM source
6. Les jobs de synchronisation Elasticsearch et Vespa synchronisent les données triées dans leurs index respectifs
7. Les couches API relient les systèmes de recherche aux applications clientes

Ce workflow garantissait que chaque valeur d’attribut normalisée – qu’elle soit triée par IA ou manuellement définie – était cohérente dans la recherche, le merchandising et l’expérience client.

Pourquoi l’approche hors ligne était la bonne

Les pipelines en temps réel auraient introduit des latences imprévisibles, des coûts de calcul plus élevés et des dépendances fragiles. Les jobs hors ligne permettaient plutôt :

• un traitement batch efficace
• des appels LLM asynchrones sans pression en temps réel
• des mécanismes de relance robustes et des files d’attente d’erreurs
• des fenêtres de validation humaine
• des coûts de calcul prévisibles et maîtrisés

Le compromis était un léger délai entre la collecte des données et leur affichage, mais le gain – une fiabilité à grande échelle – est précieux pour les clients.

Impacts business et techniques

La solution a permis d’atteindre des résultats mesurables :

• tri cohérent des attributs sur plus de 3 millions de SKU
• tri numérique prévisible grâce à des fallback déterministes
• contrôle décentralisé par tagging manuel
• pages produits plus propres et filtres plus intuitifs
• pertinence et précision accrues dans la recherche
• confiance accrue des clients et taux de conversion amélioré

Ce n’était pas qu’un projet technique ; c’était un levier directement mesurable pour l’expérience utilisateur et la croissance du chiffre d’affaires.

Leçons clés pour l’échelle produit

• Les systèmes hybrides surpassent l’IA pure à grande échelle. Les garde-fous et mécanismes de contrôle sont essentiels.
• Le contexte est le multiplicateur de précision des LLM. Des entrées propres et pertinentes pour la catégorie conduisent à des sorties fiables.
• Le traitement hors ligne n’est pas un compromis, mais une nécessité architecturale pour le débit et la résilience.
• Les options de surcharge humaine renforcent la confiance. Les systèmes contrôlés par l’humain sont plus rapidement adoptés.
• La qualité des données en entrée détermine la fiabilité en sortie. La nettoyage n’est pas une surcharge, mais la base.

Réflexion finale

Normaliser des valeurs d’attribut peut sembler simple – jusqu’à ce qu’il faille le faire pour des millions de variantes de produits. En combinant l’intelligence des modèles linguistiques avec des règles déterministes et des contrôles humains, un problème caché et tenace a été transformé en un système élégant, maintenable.

Cela rappelle que certains des succès techniques les plus précieux ne viennent pas d’innovations brillantes, mais de la résolution systématique de problèmes invisibles – ceux qui agissent chaque jour sur chaque page produit, mais reçoivent rarement d’attention.