← Blog
2026-03-03 · 7 min de lecture

Construire un modèle de lead scoring au-dessus d’une API ecommerce

Schéma bleu d’un pipeline de lead scoring déroulé de gauche à droite, des boutiques aux gates puis aux points jusqu’à un score unique, avec un arc de calibration qui reboucle vers le départ.

Presque tous ceux qui construisent un lead score construisent le mauvais objet. Ils essaient de calculer la qualité d’un lead, comme si la qualité était une propriété du prospect. Elle ne l’est pas. Un lead n’est ni bon ni mauvais dans l’absolu ; il est bon ou mauvais pour une offre, à un prix, dans une fenêtre de temps. Ratez ça au moment de la conception et aucune arithmétique ne rattrapera la sortie ensuite.

Ce qui suit est un guide de construction posé sur les champs qu’une API ecommerce vous donne réellement : domain, platform, country, productCount, monthlyTraffic, organicKeywords, apps, paymentMethods, contactEmail, le bloc Google Business, la série trend. Gates, familles de signal, poids, normalisation, décroissance, calibration. C’est plus ennuyeux qu’un article sur le machine learning, et ça marchera encore au neuvième mois — ce qui est la seule chose qui compte.

Scorez une seule offre, sinon le score ne veut rien dire

Le nombre doit répondre à une question assez étroite pour être réfutable : quelle est la probabilité que cette boutique achète cette chose précise, à ce prix précis, dans les quatre-vingt-dix prochains jours ? Si vous vendez trois choses, vous construisez trois scores. Ça ressemble à trois fois plus de travail et c’est en réalité moins, parce que chacun est plus simple et peut être débogué indépendamment.

Le coût d’ignorer ce principe est subtil et cher. Un score unique et mélangé classera systématiquement un distributeur à quarante mille SKU au-dessus d’une marque DTC à trois cents SKU, pour tout, parce que le distributeur est plus gros sur chacun des axes que vous avez mesurés. C’est le bon lead pour votre offre de gestion de flux et le mauvais pour votre offre créative, et le chiffre mélangé ne sait pas exprimer ça.

Nommez-les en conséquence et sans imagination. Un champ score_local, un score_cro, un score_flux. Des noms qui survivent au contact d’une deuxième personne dans l’équipe valent mieux que de l’élégance.

Les gates avant les points

Disqualifier est plus rapide et plus propre que classer, et les commerciaux vraiment bons en outbound passent l’essentiel de leur énergie à retirer des gens de la liste plutôt qu’à les trier. Intégrez le même réflexe dans le modèle. Un gate est un booléen qui, lorsqu’il échoue, supprime la fiche entièrement : pas de points, pas de crédit partiel, pas d’apparition en bas d’une vue où quelqu’un finira par la travailler par désespoir.

Les gates sont en général évidents une fois écrits noir sur blanc : plateforme dans votre liste supportée, pays dans une langue où vous savez vendre, productCount au-dessus du plancher où votre travail a de quoi agir, monthlyTraffic au-dessus du niveau où un gain en pourcentage devient un vrai nombre, pas déjà client, absent de toute liste de suppression.

Schéma bleu de 153 515 lignes entrantes traversant cinq fentes de gate, dont trois marquées plateforme, pays et trafic, seules quelques milliers ressortant dans un petit bloc empilé.
Ordonnez les fentes selon ce que chacune retire, la plus dure en premier, pour que les vérifications coûteuses ne tournent jamais que sur les survivants.

Appliqués en premier, les gates font passer 153 515 boutiques à quelques milliers avant qu’un seul point ne soit calculé. Tout ce qui suit devient bon marché et, surtout, tout ce qui suit devient relisible par un humain capable de vraiment lire la liste.

Trois familles de signal, et seulement trois

La capacité à payer, la preuve du problème que vous résolvez, et la joignabilité. Si un signal candidat n’appartient à aucune de ces trois familles, c’est une description du prospect et pas un prédicteur de la vente, et il n’a rien à faire dans le score. Cette seule règle élimine à peu près la moitié des champs qu’on est tenté d’inclure.

La capacité s’appuie sur monthlyTraffic, productCount, le palier de prix que vous dérivez du catalogue, reviewsCount comme proxy grossier de l’ancienneté, la plateforme comme proxy de sophistication et de budget, et la stack d’apps détectée — une boutique qui paie six apps par abonnement a démontré, avec de l’argent, qu’elle achète du logiciel. Ce dernier signal est sous-estimé parce qu’il est comportemental et pas déclaratif.

La preuve, c’est ce que votre offre répare, exprimé en données. Une agence de flux cherche un gros catalogue sans aucune app shopping détectée. Un cabinet de CRO cherche du trafic significatif à côté d’une liste de moyens de paiement maigre ou d’un mauvais ratio mots-clés sur produits. Un spécialiste du local cherche une fiche non revendiquée, zéro photo ou presque, une note sous quatre. Une agence email cherche une structure de prix propice au réachat et aucun service d’emailing dans la stack.

La joignabilité n’a rien de glamour et décide tout : contactEmail présent, réseaux sociaux présents, un téléphone ou une adresse sur la fiche Google. Une boutique parfaitement qualifiée que vous ne pouvez pas contacter vaut exactement zéro, et prétendre le contraire gonfle votre liste de lignes qui ne se transformeront jamais en quoi que ce soit.

Les poids : fixés à la main, puis discutés

Vous n’avez pas assez de deals signés pour ajuster un modèle, et personne d’autre non plus au démarrage. Douze victoires ne supportent pas une régression, et un modèle entraîné sur douze victoires encodera avec assurance les accidents de votre premier trimestre. Attribuez les poids à la main, en nombres ronds, et écrivez le raisonnement en commentaire à côté de chacun.

Une forme de départ raisonnable : preuve cinquante, capacité trente-cinq, joignabilité quinze, avec pas plus de quatre ou cinq entrées par famille. Ajouter une douzième entrée donne une impression de rigueur et c’est presque toujours du bruit, parce que la douzième corrèle avec la troisième et que vous venez de compter deux fois en silence.

Schéma bleu de trois barres d’épaisseurs inégales — preuve 50, capacité 35, joignabilité 15 — convergeant en une colonne de trois segments empilés sous une ligne de plafond marquée 100.
Rien n’interdit un poids négatif — l’app d’un concurrent détectée dans la stack peut légitimement retrancher du segment preuve.

Utilisez des paliers plutôt que des fonctions linéaires. Trafic sous mille : zéro. De mille à dix mille : dix. De dix mille à cinquante mille : vingt-cinq. Au-dessus de cinquante mille : trente. Les paliers sont lisibles par un humain, ils se dégradent proprement quand l’estimation sous-jacente se trompe de quarante pour cent — et les estimations de trafic se trompent de quarante pour cent en permanence — et ils peuvent être audités par quelqu’un qui n’écrit pas de code.

Plafonnez le total à cent et ne laissez jamais une seule entrée dépasser trente environ. Si un champ suffit à propulser une fiche dans le décile du haut, vous n’avez pas construit un score, vous avez construit un alias très cher pour ce champ.

Normalisez par pays, par plateforme et par catégorie

Les seuils absolus punissent systématiquement les petits marchés. Trois mille visites mensuelles sur une boutique néerlandaise peuvent représenter un business plus sain et plus rentable que trois mille sur une boutique américaine de la même catégorie, parce que le marché adressable et l’intensité concurrentielle ne sont pas les mêmes. Scorez-les à l’identique et votre liste dérivera vers l’américain et le Shopify sans que personne ne l’ait décidé.

Le correctif, c’est le percentile dans la cohorte plutôt que la valeur brute. Calculez la distribution de trafic par couple pays et plateforme, puis scorez le percentile de la boutique à l’intérieur de sa propre cohorte. Ça coûte une agrégation de plus dans le pipeline et ça supprime un biais qu’il vous aurait fallu six mois pour remarquer.

Appliquez le même traitement à productCount, qui veut dire des choses franchement différentes sur PrestaShop et sur JouwWeb, et à reviewsCount, qui varie énormément selon la catégorie et la culture nationale de l’avis. Un fournisseur de restaurants à quatre cents avis et une boutique de mode à quatre cents avis ne sont pas des objets comparables.

Fraîcheur, décroissance et les champs qui vieillissent différemment

Un score calculé en mars et utilisé en septembre est un mensonge horodaté. Attachez un computed_at à chaque score et faites décroître votre confiance en lui plutôt que le nombre lui-même. Après quatre-vingt-dix jours, marquez-le périmé dans l’interface. Après cent quatre-vingts, refusez qu’il alimente une séquence.

Les champs vieillissent à des rythmes très différents et votre calendrier de rafraîchissement doit le refléter. Le trafic et le trend vieillissent en semaines. Les apps détectées et les emails de contact vieillissent en deux mois. productCount vieillit en mois. Le pays et la plateforme vieillissent en années — sauf quand une boutique change de plateforme, ce qui arrive tout le temps et constitue en soi l’un des signaux d’achat les plus forts du dataset.

En pratique : un job mensuel sur votre segment actif pour rafraîchir les champs volatils, un job trimestriel sur tout le reste pour les champs structurels, et un contrôle de vie juste avant chaque lancement de séquence. Trois jobs, et ils vous feront économiser plus que n’importe quelle amélioration de copy cette année.

La calibration est la seule chose qui rend le score réel

Un score sans retour sur les résultats, c’est de l’astrologie faite avec de l’arithmétique. Le mécanisme qui le rend réel est d’une simplicité triviale et presque universellement sauté : écrivez le score dans le CRM au moment du premier contact, figez-le là, puis comparez les déciles avec les réponses, les rendez-vous obtenus et les deals signés.

Ce que vous testez, c’est la monotonie, pas la précision. Si le décile du haut répond mieux que le cinquième, et le cinquième mieux que celui du bas, le score fait son travail même si les chiffres absolus sont peu flatteurs. Si les déciles sont plats, l’une de vos trois familles est fausse — et c’est presque toujours la preuve, parce que les gens scorent instinctivement ce qui est facile à mesurer plutôt que ce qui prédit un achat.

Schéma bleu de deux rangées de déciles, celle du haut en escalier descendant du décile haut au décile bas et marquée monotone, celle du bas plate, avec une boucle de repondération qui revient vers un petit bloc.
L’escalier n’a qu’à descendre : un escalier peu pentu reste un score qui fonctionne, et la pente compte bien moins que le sens.

Révisez tous les trimestres, changez une seule chose par révision, et gardez la définition de la version précédente pour pouvoir comparer les cohortes honnêtement. Changer quatre poids d’un coup puis constater que ça s’est amélioré ne vous apprend rien de réutilisable.

Un exemple travaillé, et les modes d’échec par ordre de fréquence

Un freelance CRO qui vend un audit plus retainer à 4 500 € pourrait poser ses gates sur Shopify ou WooCommerce, un pays de l’Union européenne, un trafic au-dessus de huit mille, contactEmail présent. Preuve : prix médian à 60 € ou plus, productCount entre cent et trois mille, aucune app orientée conversion détectée, positions qui montent pendant que le trafic reste plat. Capacité : percentile de trafic dans la cohorte, palier de reviewsCount, nombre d’apps payantes. Joignabilité : email plus au moins un profil social. Cinq à douze entrées au total, toutes défendables à voix haute.

Les modes d’échec, à peu près par ordre de fréquence : scorer ce qui est facile à mesurer au lieu de ce qui prédit ; trop d’entrées ; laisser un seul champ dominer le total ; ne jamais figer le score au moment du contact, ce qui rend la calibration impossible à jamais ; et bâtir un score impeccable pour une offre dont personne ne veut, ce qu’aucune arithmétique n’a jamais résolu.

Gardez l’ambition modeste et le score devient réellement utile. Il ne vend rien et il ne prédit pas le chiffre d’affaires. Il décide dans quel ordre vous travaillez, et il vous permet d’arrêter de penser à cent quarante-huit mille boutiques. C’est toute la proposition de valeur, et c’est largement suffisant.

Mettez ce playbook en pratique

153 000+ boutiques e-commerce françaises vérifiées, interrogeables par votre agent IA. À partir de 49 €/mois.

Obtenir ma clé API