Commerce en gros : Comment un ingénieur logiciel trie des millions d'attributs de produits chaotiques

La plupart des débats sur la scalabilité du commerce électronique tournent autour de sujets sexuels : systèmes de recherche distribués, gestion en temps réel des stocks, algorithmes de recommandation. Mais derrière se cache un problème plus discret, mais plus tenace : la gestion des valeurs d’attributs. C’est un bruit technique présent dans chaque grande boutique en ligne.

Le problème silencieux : pourquoi les valeurs d’attributs compliquent tout

Les attributs produits sont fondamentaux pour l’expérience client. Ils alimentent filtres, comparaisons et classement dans la recherche. En théorie, c’est simple. En pratique : les valeurs brutes sont chaotiques.

Une simple valeur pourrait ressembler à : “XL”, “Small”, “12cm”, “Large”, “M”, “S”. Couleurs ? “RAL 3020”, “Crimson”, “Red”, “Dark Red”. Matériau ? “Steel”, “Carbon Steel”, “Stainless”, “Stainless Steel”.

Pris isolément, ces incohérences semblent inoffensives. Mais multipliez cela par 3 millions de SKUs, chacun avec une dizaine d’attributs – le problème devient systémique. Les filtres se comportent de manière imprévisible. Les moteurs de recherche perdent en pertinence. Les clients expérimentent des recherches plus lentes et frustrantes. Et en backend, les membres des équipes sont submergés par la correction manuelle des données.

Un ingénieur logiciel chez Zoro faisait face à ce défi : un problème facile à négliger, mais qui impactait chaque fiche produit.

La voie vers une automatisation intelligente sans perte de contrôle

Le premier principe était clair : pas de boîte noire d’IA. De tels systèmes sont difficiles à faire confiance, à déboguer ou à faire évoluer.

À la place, une pipeline hybride a été développée, qui :

• reste explicable
• fonctionne de manière prévisible
• scale réellement
• est contrôlable par l’humain

Le résultat combine la pensée contextuelle des modèles linguistiques modernes avec des règles fixes et des contrôles. Une IA encadrée, pas hors de contrôle.

Vue d’ensemble de l’architecture : comment tout s’articule

Tout le traitement s’effectue dans des jobs en arrière-plan, en mode batch, pas en temps réel. Ce n’était pas un compromis – c’était une nécessité architecturale.

Les pipelines en temps réel peuvent sembler attrayants, mais conduisent à :

• une latence imprévisible
• des dépendances fragiles
• des pics de calcul coûteux
• une fragilité opérationnelle

Le traitement batch permet plutôt :

• un débit élevé : traiter des millions de données sans impacter le système en ligne
• une résilience : les erreurs n’affectent jamais le trafic client
• un contrôle des coûts : planifier les calculs lors de périodes creuses
• une isolation : la latence des modèles linguistiques n’impacte jamais les fiches produits
• une cohérence : les mises à jour sont atomiques et prévisibles

L’architecture fonctionne ainsi :

1. Les données produits proviennent du système PIM
2. Un job d’extraction récupère les valeurs brutes et le contexte
3. Ces données sont envoyées à un service de tri basé sur l’IA
4. Les documents mis à jour sont stockés dans MongoDB
5. La synchronisation sortante met à jour le système d’origine
6. Elasticsearch et Vespa synchronisent les données triées
7. Les API relient le tout à l’interface client

Les quatre couches de la solution

Couche 1 : préparation des données

Avant d’appliquer l’intelligence, une étape de prétraitement claire. Suppression des espaces. Déduplication des valeurs. Contextualisation des breadcrumbs de catégorie en chaînes structurées. Suppression des entrées vides.

Cela peut sembler basique, mais cela améliore considérablement la performance de l’IA. Entrée de déchets, sortie de déchets – à cette échelle, de petites erreurs peuvent devenir de gros problèmes plus tard.

Couche 2 : tri intelligent avec contexte

Le modèle linguistique n’était pas simplement un outil de tri. Il réfléchissait aux valeurs.

Le service recevait :

• des valeurs d’attribut nettoyées
• des métadonnées de catégorie
• des définitions d’attributs

Avec ce contexte, le modèle pouvait comprendre :

• que “Tension” dans des outils électriques doit être numérique
• que “Taille” dans le prêt-à-porter suit une progression connue
• que “Couleur” peut suivre des standards RAL
• que “Matériau” a des relations sémantiques

Le modèle renvoyait :

• des valeurs ordonnées dans un ordre logique
• des noms d’attributs affinés
• une décision : tri déterministe ou contextuel

Couche 3 : fallback déterministe

Tous les attributs n’ont pas besoin d’intelligence. Les plages numériques, valeurs avec unités, et quantités simples profitent de :

• un traitement plus rapide
• une sortie prévisible
• des coûts plus faibles
• aucune ambiguïté

La pipeline détectait automatiquement ces cas et utilisait une logique déterministe. Cela maintenait le système efficace et évitait des appels coûteux à des LLM.

Couche 4 : override humain

Chaque catégorie pouvait être taguée comme :

• LLM_SORT : décision du modèle
• MANUAL_SORT : ordre défini par l’humain

Ce système dual permettait aux humains de prendre la décision finale, tandis que l’intelligence prenait en charge la majorité du travail. Cela renforçait aussi la confiance – les marchands pouvaient toujours écraser le modèle.

De chaos à clarté : résultats pratiques

La pipeline a transformé des données brutes chaotiques :

Ces exemples illustrent comment la compréhension du contexte peut être combinée à des règles claires.

Persistance et contrôle sur toute la chaîne

Tous les résultats étaient stockés directement dans une MongoDB produits. MongoDB devenait la seule source pour :

• valeurs d’attribut triées
• noms d’attributs affinés
• tags de tri spécifiques à la catégorie
• ordres de tri propres à chaque produit

Cela facilitait la vérification, la correction, la ré-exécution par catégorie, et la synchronisation avec d’autres systèmes.

Après tri, les valeurs alimentaient :

• Elasticsearch pour la recherche par mots-clés
• Vespa pour la recherche sémantique et vectorielle

Cela garantissait que les filtres s’affichaient dans un ordre logique, que les fiches produits montraient des attributs cohérents, et que les moteurs de recherche classaient mieux les produits.

Pourquoi ne pas simplement faire en temps réel ?

Le traitement en temps réel aurait signifié :

• une latence imprévisible pour les requêtes en ligne
• des coûts de calcul plus élevés pour des résultats immédiats
• des dépendances fragiles entre systèmes
• une complexité opérationnelle et des risques d’erreurs pour le trafic client

Les jobs batch offraient plutôt :

• une efficacité à l’échelle de millions de produits
• des appels LLM asynchrones sans impact en direct
• une logique de reprise robuste
• une fenêtre pour vérification humaine
• des sorties de calcul prévisibles

Le compromis était un léger délai entre la collecte des données et leur affichage. L’avantage : une cohérence à grande échelle – ce que les clients apprécient bien plus.

Impact mesurable

La solution a permis :

• une cohérence dans le tri des attributs sur plus de 3 millions de SKUs
• un ordre numérique prévisible grâce à des fallback déterministes
• un contrôle métier via le tagging manuel
• des fiches produits plus propres et des filtres plus intuitifs
• une meilleure pertinence et un meilleur classement dans la recherche
• une confiance accrue des clients et de meilleurs taux de conversion

Ce n’était pas qu’un gain technique – c’était aussi une victoire pour l’expérience utilisateur et les résultats business.

Leçons clés pour les ingénieurs logiciels en e-commerce

• Les pipelines hybrides surpassent l’IA pure à grande échelle. L’intelligence a besoin de garde-fous.
• Le contexte améliore considérablement la précision du modèle linguistique.
• Les jobs batch sont essentiels pour le débit et la résilience.
• Les mécanismes d’override humain renforcent la confiance et l’acceptation.
• Des entrées propres sont la base pour des sorties fiables.

Conclusion

Trier des valeurs d’attributs paraît simple. Mais quand cela concerne des millions de produits, cela devient un vrai défi.

En combinant l’intelligence des modèles linguistiques avec des règles claires, du contexte et un contrôle humain, un problème complexe et caché a été transformé en un système propre et scalable.

Cela rappelle que certains des plus grands succès viennent de la résolution de problèmes ennuyeux – ceux qui sont faciles à négliger, mais qui apparaissent sur chaque fiche produit.