Du chaos à la clarté : comment l'intelligence artificielle transforme les catalogues e-commerce

Dans le commerce électronique, les techniciens parlent souvent de grands problèmes d’infrastructure : architecture de recherche, gestion en temps réel des stocks, machines de personnalisation. Mais sous la surface se cache un problème plus sournois, qui ronge presque chaque commerçant en ligne : la normalisation des attributs produits. Un catalogue chaotique avec des valeurs incohérentes pour la taille, la couleur, le matériau ou les spécifications techniques sabote tout ce qui suit – les filtres fonctionnent de manière peu fiable, les moteurs de recherche perdent en précision, la correction manuelle des données consomme des ressources.

En tant qu’ingénieur Full-Stack chez Zoro, je traitais quotidiennement ce problème : comment mettre de l’ordre dans plus de 3 millions de SKU, chacun avec une dizaine d’attributs ? La réponse ne résidait pas dans une boîte noire d’IA, mais dans un système hybride intelligent, combinant la puissance des LLM avec des règles métier claires et des mécanismes de contrôle manuel.

Le problème à grande échelle

A première vue, les incohérences d’attributs semblent inoffensives. Prenons les dimensions : « XL », « Small », « 12cm », « Large », « M », « S » – tout cela signifie la même chose, mais rien n’est standardisé. Pour les couleurs, c’est pareil : « RAL 3020 », « Crimson », « Red », « Dark Red » – parfois des standards de couleurs (RAL 3020 est une couleur normalisée), parfois des noms fantaisie.

Multipliez ce chaos par des millions de produits, et les impacts deviennent dramatiques :

• Les clients voient des filtres chaotiques et abandonnent la recherche
• Les moteurs de recherche ne peuvent pas classer correctement les produits
• Les analyses montrent de fausses tendances
• Les équipes de merchandising sont submergées par la correction manuelle des données

L’approche stratégique : IA hybride avec règles

Mon objectif n’était pas un système d’IA mystérieux, opérant une magie noire. Je voulais un système qui :

• Explique ses décisions – on comprend pourquoi une décision a été prise
• Prévoit son comportement – pas de pannes surprises ou d’anomalies
• Scalabilise – sur des millions d’attributs
• Reste contrôlable par l’humain – les équipes métier peuvent intervenir

Le résultat fut une pipeline combinant l’intelligence des LLM avec des règles claires et un contrôle métier. Une IA encadrée, pas une IA sans limites.

Pourquoi traiter hors ligne plutôt qu’en temps réel ?

La première décision architecturale était fondamentale : tout traitement des attributs s’effectuait en jobs asynchrones en arrière-plan, pas en temps réel. Cela peut sembler un compromis, mais c’était une décision stratégique aux avantages énormes :

Les pipelines en temps réel auraient causé :

• Des latences imprévisibles sur les pages produits
• Des dépendances fragiles entre systèmes
• Des coûts explosifs lors de pics de trafic
• Un impact direct sur l’expérience client

Les jobs hors ligne offraient :

• Un débit élevé : de gros lots sans impacter le système en production
• Une robustesse : les erreurs de traitement n’affectent jamais le client
• Une maîtrise des coûts : effectuer les calculs en périodes de faible trafic
• Une isolation : la latence des LLM est isolée des services orientés utilisateur
• Des mises à jour atomiques : changements cohérents ou pas de changement du tout

Séparer les systèmes client et traitement de données est essentiel quand on travaille avec cette quantité de données.

La pipeline de traitement

Le processus se déroulait en plusieurs phases :

Phase 1 : Nettoyage des données

Avant même que l’IA ne soit utilisée, les données passaient par une étape de pré-traitement :

• Suppression des espaces superflus
• Élimination des valeurs vides
• Dédouanement des doublons
• Conversion du contexte catégoriel en chaînes structurées

Ce simple étape améliorait considérablement la précision du LLM. Le principe : garbage in, garbage out. À cette échelle, de petites erreurs deviennent de gros problèmes plus tard.

Phase 2 : Raisonnement IA avec contexte

Le LLM ne triait pas simplement par ordre alphabétique. Il réfléchissait aux valeurs. Le service recevait :

• Des valeurs d’attribut nettoyées
• Des breadcrumbs de catégorie (par ex. « Outils électriques > Perceuses »)
• Des métadonnées d’attribut

Avec ce contexte, le modèle comprenait :

• Que « tension » dans les outils électriques doit être triée numériquement
• Que « taille » suit une progression connue (S, M, L, XL)
• Que « couleur » peut suivre certains standards comme RAL 3020
• Que « matériau » a des relations sémantiques (Acier > Acier inoxydable > Acier au carbone)

Le modèle renvoyait :

• Des valeurs d’attribut ordonnées
• Des noms d’attribut affinés
• Une classification : doit-on trier de façon déterministe ou contextuelle ?

Phase 3 : FallBack déterministes

Tous les attributs ne nécessitent pas l’IA. Beaucoup sont mieux gérés par une logique claire :

• Plages numériques (2cm, 5cm, 12cm, 20cm → tri croissant)
• Valeurs avec unités
• Collections catégoriques

La pipeline détectait automatiquement ces cas et appliquait une logique déterministe. Cela réduisait les coûts et garantissait la cohérence.

Phase 4 : Contrôle humain

Les attributs critiques pour le business nécessitaient une étape de validation manuelle. Chaque catégorie pouvait être marquée :

• LLM_SORT : décision du modèle
• MANUAL_SORT : ordre défini par le marchand

Ce système dual donnait le dernier mot à l’humain. Si le LLM faisait une erreur, le marchand pouvait la corriger sans arrêter la pipeline.

Persistance et systèmes en aval

Tous les résultats étaient stockés directement dans MongoDB – une seule source de vérité pour :

• Les valeurs d’attribut triées
• Les noms d’attribut affinés
• Les tags de tri par catégorie
• L’ordre de tri au niveau produit

Ensuite, les données alimentaient deux systèmes :

• Elasticsearch : pour la recherche par mots-clés, avec filtres basés sur des attributs propres
• Vespa : pour la recherche sémantique et vectorielle, où la cohérence améliore le classement

Les filtres apparaissent maintenant dans un ordre logique. Les pages produits affichent des spécifications cohérentes. Les moteurs de recherche classent plus précisément. Les clients naviguent dans les catégories sans frustration.

Résultats concrets

La pipeline a transformé des données brutes chaotiques en sorties propres et exploitables :

Cette transformation a été appliquée de façon cohérente sur plus de 3 millions de SKU.

Impacts

Les résultats dépassaient largement la technique :

• Ordre cohérent des attributs sur tout le catalogue
• Comportement prévisible pour les valeurs numériques grâce aux fallbacks déterministes
• Contrôle métier via un système de tagging manuel
• Pages produits propres avec des filtres intuitifs
• Meilleure pertinence de recherche pour les clients
• Confiance accrue et meilleures conversions

Ce n’était pas qu’une victoire technique, mais un succès business.

Enseignements clés

• Les pipelines hybrides surpassent l’IA seule à grande échelle. Les garde-fous ne sont pas un obstacle – ce sont une fonctionnalité.
• Le contexte est tout : un LLM avec info catégorielle et métadonnées est 10x plus précis qu’un sans.
• Le traitement hors ligne est essentiel : avec cette quantité de données, on a besoin d’efficacité batch et de tolérance aux erreurs, pas de latence en temps réel.
• Le contrôle humain renforce la confiance : les équipes acceptent l’IA quand elles peuvent la maîtriser.
• L’hygiène des données est la base : des entrées nettoyées donnent des sorties fiables. Toujours.

Conclusion

Normaliser des valeurs d’attribut peut sembler trivial – jusqu’à ce qu’il faille le faire en temps réel pour des millions de produits. En combinant l’intelligence des LLM, des règles claires et un contrôle humain, j’ai transformé un problème caché et tenace en un système scalable.

C’est un rappel : certains des grands succès en e-commerce ne viennent pas de technologies sexy, mais de la résolution de problèmes ennuyeux – ceux qui touchent chaque fiche produit.