Un comparateur ne casse pas sur son interface, il casse sur ses prix. La première version se joue dans la chaîne qui va chercher la donnée, la vérifie et refuse de publier ce qui n'a pas de sens. Ce que la première version doit contenir, ce qui attend, et le piège qui a coûté trois mois à un fondateur.
Publié le
Un comparateur vend une seule promesse : le prix affiché est le bon. Tout le reste, le design, les filtres, les comptes, ne vaut rien si cette promesse casse. Et elle casse de trois façons, toujours les mêmes.
Notre principe de conception
Une donnée manquante et signalée vaut mieux qu’une donnée fausse et publiée. Un comparateur qui dit « prix non disponible » garde la confiance de ses utilisateurs. Un comparateur qui affiche un prix faux la perd, et ne le sait pas.
La première version d’un comparateur, c’est une chaîne de prix avec des contrôles, et une interface simple posée dessus. Les contrôles ne sont pas une option de la version suivante : sans eux, le produit ment dès le premier jour.
| Le contrôle | Ce qu’il attrape |
|---|---|
| Lecture du prix à la source, dans sa devise d’origine | Les conversions et les substitutions faites par un intermédiaire |
| Devise et TVA en configuration explicite par source, validées par vous | Les coefficients en dur qui deviennent faux quand une boutique change |
| Plausibilité de chaque prix par rapport à son propre historique | Le zéro, le ×1 000, la mauvaise variante |
| Ratio de prix changés par source à chaque passage | Le changement de format d’une boutique, qui fait bouger tout son catalogue d’un coup |
| Suspension d’une source incohérente, dernières valeurs saines conservées | La publication de données douteuses, sans faire disparaître la boutique |
| Récapitulatif écrit à chaque passage | Les 33 boutiques suspendues que personne n’avait vues |
Votre chaîne de prix a-t-elle ces contrôles ? Si vous ne savez pas, décrivez votre comparateur et vos sources. Nous vous disons ce qui manque.
Décrire mon projetDirectement de la boutique, ou d’une plateforme d’extraction intermédiaire ? La seconde va plus vite le premier jour et coûte chaque mois. La première demande un lecteur par type de boutique, mais la plupart des boutiques en ligne tournent sur trois ou quatre plateformes qui exposent leurs catalogues de façon structurée : un seul lecteur couvre des dizaines de sources. Sur le comparateur repris, 57 boutiques sur 64 tournaient sur la même plateforme et se lisaient avec le même code, au lieu de 57 blocs différents.
Publier quand même, ne rien publier, ou garder la dernière valeur saine ? La réponse conditionne la confiance et le coût de l’exploitation. Notre position est la troisième : la source est suspendue, ses derniers prix justes restent affichés avec leur date, et vous recevez un message qui dit quoi vérifier. Le comparateur ne perd ni sa boutique ni sa crédibilité.
Par son titre, par son adresse, par une référence de la boutique ? C’est la décision qu’on regrette le plus tard. Le comparateur repris identifiait les produits par leur titre : 520 titres en doublon sur 11 000 lignes, et la fiche produit affichait parfois un article d’une autre boutique. Une clé stable par source, posée dès la première version, évite une migration douloureuse plus tard.
Ce que nous livrons
Une acquisition par source, configurée dans un fichier et non dans le code ; la normalisation des devises et de la TVA, validée avec vous source par source ; les six contrôles du tableau ; l’historique des prix ; le récapitulatif à chaque passage ; une interface de recherche et de fiche produit ; une procédure d’ajout de source que vous appliquez seul. Le plus souvent un MVP standard, parce que la chaîne de données pèse autant que l’interface. Hors première version : prix dégressifs par quantité, alertes de baisse pour les utilisateurs, recommandations, historique visible côté public.
Décrivez les sources et ce que vos utilisateurs doivent pouvoir comparer. Le cadrage dit ce qui va dans la première version, et à quel prix.