#ManoMano — Moteur de recherche interne IA sémantique + recommandations cross-sell sur 3 M+ SKUs

Mission 14 semaines. Architecture LLM embeddings + MLOps déployée sur catalogue bricolage/jardin/maison 3 millions de références. Taux de rebond catalogue réduit de 38 %. Conversion panier +31 %. Panier moyen +22 %. A/B testing continu en production depuis S1 2025.

#Contexte client

ManoMano est une marketplace pure-player spécialisée dans le bricolage, le jardinage et l'aménagement de la maison, fondée en 2013 à Bordeaux par Christian Raisson et Philippe de Chanville. À la date de la mission (S2 2024), la plateforme comptait plus de 3 millions de SKUs actifs issus de 7 500 marchands partenaires, environ 12 millions de visites mensuelles consolidées sur les six marchés où elle opère (France, Espagne, Italie, Allemagne, Belgique, Royaume-Uni), et un chiffre d'affaires annuel récurrent estimé autour de 40 millions d'euros. La verticalité du catalogue — bricolage outillage, jardinage, peinture revêtements, plomberie, électricité, quincaillerie, mobilier extérieur — crée une complexité taxonomique réelle : un même besoin utilisateur peut s'exprimer par des centaines de formulations différentes selon le niveau d'expertise du client (artisan professionnel, particulier débutant, bricoleur confirmé), et les synonymes techniques sont légion (scie sauteuse vs scie à chantourner, perceuse-visseuse vs visseuse à percussion, chevron vs bastaing). Cette diversité lexicale, combinée à la profondeur du catalogue 3 M+ SKUs avec des données produit de qualité hétérogène selon les marchands (fiches très complètes vs fiches minimalistes), constituait un terrain particulièrement difficile pour tout moteur de recherche basé sur de la correspondance lexicale classique. La croissance organique très rapide entre 2019 et 2023 avait laissé peu de temps aux équipes techniques pour refondre l'infrastructure de recherche. Le moteur historique, basé sur Elasticsearch avec des règles de boost manuelles et un dictionnaire de synonymes maintenu à la main par une équipe de 3 catalogueurs, atteignait ses limites : 31 % des requêtes longue traîne retournaient zéro résultat ou des résultats perçus comme hors sujet par les utilisateurs (mesure NPS interne), et la maintenance du dictionnaire de synonymes était devenue un goulot d'étranglement opérationnel consommant 40 % du temps d'une équipe dédiée. L'équipe Produit de ManoMano, pilotée par un Head of Product ayant une solide culture data et une connaissance fine des mécanismes de conversion e-commerce, cherchait une approche scalable qui sortirait définitivement de la logique règles manuelles pour basculer vers une approche apprentissage automatique. Le brief initial transmis par le Head of Product était précis : refonte du moteur de recherche interne avec une architecture LLM embeddings, déploiement d'un système de recommandations cross-sell et upsell basé sur la similarité sémantique des produits, réduction mesurable du taux de rebond sur les pages catalogue, et mise en place d'un framework A/B testing permettant d'itérer en continu sans mobiliser l'équipe backend à chaque changement. Budget alloué : 280 000 euros sur la mission de design et déploiement, hors coûts d'infrastructure GCP récurrents. Délai demandé : 16 semaines maximum pour un déploiement en production sur le marché France, avec extension sur les autres marchés en vague 2.

#Le défi

Le challenge technique et produit de cette mission s'articulait autour de quatre axes de complexité simultanés, chacun suffisant à justifier une mission à part entière. Premier axe : la volumétrie et la qualité hétérogène des données catalogue. Travailler sur 3 millions de SKUs signifiait indexer, nettoyer et vectoriser une masse de données produit dont la qualité variait drastiquement selon les marchands partenaires. Certains marchands structurés livraient des fiches produit avec titres normalisés, descriptions longues riches, attributs complets et images référencées. D'autres — notamment les petits marchands artisanaux — livraient des fiches minimalistes : titre en minuscules non structuré, description de 2 lignes, attributs vides. La chaîne de vectorisation devait absorber cette hétérogénéité sans dégrader la qualité des embeddings sur les fiches pauvres, sous peine de créer un moteur de recherche à deux vitesses qui aurait favorisé les gros marchands au détriment des plus petits. Deuxième axe : la complexité lexicale du domaine bricolage. Le vocabulaire du bricolage et de l'outillage professionnel est dense, fortement polysémique et partiellement dialectal selon les régions et les corps de métier. Un artisan carreleur, un particulier qui fait ses premières rénovations et un chef de chantier en second œuvre n'utilisent pas le même vocabulaire pour désigner le même produit. Le modèle devait capturer ces variations sans supervision manuelle permanente, c'est-à-dire apprendre les équivalences sémantiques directement depuis le corpus produit et les logs de recherche historiques, pas depuis un dictionnaire maintenu à la main. Troisième axe : le taux de rebond catalogue structurellement élevé. À 54 % sur les pages catalogue atteintes depuis le moteur de recherche interne, le chiffre indiquait clairement que les utilisateurs ne trouvaient pas ce qu'ils cherchaient, ou trouvaient une page de résultats non pertinente qui les décourageait avant même d'explorer les produits affichés. Ce taux combinait deux sous-problèmes distincts : les requêtes sans résultat (zero-results queries, environ 31 % du volume total des requêtes) et les requêtes avec résultats mais mal ordonnés (sous-problème de ranking pertinence). Traiter uniquement l'un ou l'autre aurait produit une amélioration partielle. La mission devait adresser les deux simultanément avec une architecture unifiée. Quatrième axe : les recommandations cross-sell et upsell figées. Le système de recommandations en place depuis 2021 était basé sur des règles de co-achat calculées mensuellement en batch sur les historiques de commande. Ce système avait fonctionné correctement tant que le catalogue était limité et les patterns d'achat stables. Avec l'explosion du catalogue à 3 M+ SKUs et la diversification des catégories, les règles de co-achat statiques rataient une partie significative des associations pertinentes, notamment sur les nouvelles catégories et les produits récemment ajoutés (cold start). Le CTR sur les blocs recommandations était tombé à 4,2 % fin 2023, contre 7,1 % en 2021. Sur un volume de 12 millions de visites mensuelles, chaque point de CTR représentait un impact GMV mesurable. Un cinquième élément de complexité, transverse : la nécessité de maintenir une latence de réponse moteur inférieure à 150 ms en P95 sur l'ensemble des requêtes, y compris les requêtes longue traîne sur mobile 4G. Toute architecture embeddings qui aurait dégradé la latence de recherche en dessous de ce seuil aurait produit un effet négatif sur le taux de conversion mesuré en A/B test — une contrainte technique non négociable identifiée dès le brief initial.

#Résultats mesurés

| KPI | Résultat |

|-----|---------|

| Taux de rebond catalogue — passé de 54 % à 33,4 % sur sessions issues du moteur de recherche interne | -38 % |

| Taux de conversion sur requêtes moteur de recherche — cohorte test vs cohorte contrôle sur 8 semaines | +31 % |

| Panier moyen sur sessions avec interaction moteur de recherche ou blocs recommandations | +22 % |

| Temps médian de recherche (durée entre saisie requête et premier clic produit) — 12,3 s → 5,1 s | -59 % |

| CTR blocs recommandations cross-sell — passé de 4,2 % à 11,8 % sur les 4 surfaces déployées | +181 % |

| NDCG@10 du modèle embeddings fine-tuné domaine bricolage — vs 0,61 pour le modèle généraliste base | 0,79 |

| Latence P95 moteur hybride en production — objectif < 150 ms atteint avec marge (87 ms mesuré) | < 90 ms |

#Témoignage

"Nehos a mis en production une architecture que nos équipes internes avaient estimée à 18 mois de développement. On l'a eu en 14 semaines, avec un ROI mesurable dès la sixième semaine en A/B test. La qualité de la modélisation domaine bricolage m'a particulièrement surpris — les embeddings comprenaient "perceuse à percussion sans fil" et ses dizaines d'équivalents longue traîne sans aucune règle manuelle. Ce qui m'a convaincu de travailler avec Nehos, c'est qu'ils ont d'abord passé deux semaines à auditer nos logs de recherche et nos données catalogue avant de proposer la moindre architecture. Ils ont amené des chiffres avant d'amener des slides."

—