Posté dans : Build in Public - Geek Planet
Tu veux comprendre comment structurer un site avec des dizaines de milliers de produits sans te retrouver submergé par les problématiques techniques ? Tu te demandes comment gérer un volume aussi important tout en restant cohérent pour Google, scalable pour ton équipe, et utile pour tes utilisateurs ?
Dans ce 3ème épisode de la série « Build in Public », je vais te parler d’un sujet plus technique, mais absolument central : la structure de Geek Planet. Parce que derrière le branding, l’UX et la vision, il y a une réalité très concrète. Et dès le départ, il y a eu une question clé qui a conditionné tout le reste.
La première grande question du projet, ça a été de déterminer comment gérer le référencement d’un site avec plus de 100 000 produits.
Quand tu pars sur un nouveau domaine, l’indexation par Google est très lente au début, surtout tant que celui-ci n’a aucune autorité. Et dans ce contexte, envoyer les bots crawler des dizaines de milliers de pages faibles n’a aucun sens.
Typiquement, sur des catégories comme les peluches, certaines références se ressemblent énormément. Et si toi-même tu as du mal à expliquer ce qui différencie un produit d’un autre, Google le sentira aussi dans ton contenu.
![]()
Donc la décision a été simple : réduire la complexité au départ pour maximiser l’impact.
Au lieu de créer une page par référence produit, le choix a été de concentrer le maximum d’efforts sur des landing pages du type « figurine pop harry potter » ou « lego star wars ».
Réduction drastique du volume de pages : On se concentre sur l’essentiel plutôt que de diluer les efforts.
Crawl optimisé : Google se concentre sur les requêtes les plus importantes, celles qui ont un fort potentiel SEO.
Possibilité d’évolution : Rien n’empêche de créer plus tard des pages dédiées manuellement pour certaines références, comme des sets LEGO par exemple, qui peuvent avoir de la recherche individuellement.
Mais aujourd’hui, ce n’est pas la priorité. Et ce choix ne signifie pas qu’on ne donne pas d’information sur les produits.
Même sans pages dédiées, on propose une pop-up d’informations pour chaque produit, ce qui permet de rapidement consulter les données sans changer d’URL.
![]()
Cette pop-up inclut notamment un élément ultra utile pour l’utilisateur : un historique de prix Amazon, qui permet de prendre de meilleures décisions d’achat.
C’est d’ailleurs ce même historique qui permet de calculer les produits en réduction, en se basant sur la différence entre le prix médian et le prix actuel.
Autrement dit, même si la structure est pensée pour le SEO, on garde une logique très orientée « outil » et « valeur ajoutée », avec des fonctionnalités concrètes.
Et c’est exactement là que la partie technique devient intéressante.
Concernant les flux de produits, tout est géré par notre SaaS interne (un PIM : Product information management), qui est isolé du site.
La communication se fait via un système d’API, ce qui ouvre une possibilité très forte à long terme : faire tourner plusieurs projets ou plusieurs interfaces sur la même base, sans dépendance spécifique.
Ce PIM a été créé pour gérer trois choses :
Et l’un de ses rôles clés, c’est aussi de filtrer les produits pour éviter les erreurs d’achat. Par exemple, ne proposer que les Monopoly en français, parce que sur Amazon, les erreurs de langue sont extrêmement fréquentes.
![]()
Tout est géré automatiquement chaque jour, avec une mise à jour complète des données. Et ça, c’est un point important : le site peut tourner sans intervention humaine au quotidien.
Mais il y a une autre décision technique qui a apporté énormément de flexibilité, et que je n’aurais jamais imaginée aussi puissante au départ.
Un autre point clé du projet, c’est que le backoffice du site est géré dans un Google Sheet.
Concrètement, toutes les informations sur les licences, tous les personnages, tous les groupes de produits, tous les paramètres du PIM… tout est inscrit dans ce fichier.
![]()
Séparation claire des responsabilités : Le travail de la partie dev et celui de la partie data sont bien distincts.
Flexibilité maximale : Google Sheet permet d’utiliser des formules, ce qui rend le fichier extrêmement dynamique et permet littéralement de « coder » des règles sans toucher à une ligne de code du projet.
Accessibilité : N’importe qui peut modifier une information sans avoir de connaissance en code, ni besoin de passer par un backoffice complexe.
Ensuite, un script d’import transpose les données du Google Sheet vers les bases de données. C’est sans doute une des méthodes qui nous a fait gagner le plus de flexibilité.
Cette base nous a ensuite permis de créer les templates de pages.
Comme je le précise dans cet épisode, il est essentiel de présenter le cœur du contenu en début de page. Pour répondre à ce besoin, nous avons développé un algo de pertinence pour chaque produit dans le PIM, afin de savoir lesquels sont les plus populaires.
Sur une page comme « les figurines pop Harry Potter », on affiche donc dès le début les produits qu’on juge les plus appréciés par les internautes.
![]()
Et ensuite, au lieu de dérouler un listing monotone, on a voulu aller beaucoup plus loin.
Pour la suite de cette même page, on a développé une fonctionnalité spécifique dans le PIM qui permet de catégoriser automatiquement les personnages d’une licence.
Résultat : on se retrouve avec une page segmentée par personnage.
![]()
Différenciation forte : C’est complètement unique pour un projet de ce type, et c’est une manière très puissante de capitaliser sur la notion de personnage, qui est au cœur de la pop culture.
Navigation améliorée : Les personnages sont présentés sous forme de sommaire en début de page.
Distribution intelligente du contenu : Au lieu de mettre un gros pavé en bas de page comme on le voit partout, on peut décrire chaque personnage au fil de la page, répartir le texte naturellement, et créer une expérience bien plus agréable.
Cette segmentation, on l'a appelée des « bundles ». Un bundle peut contenir : un titre, du texte, des produits, des images, une page dédiée et tout un tas de données. On en a actuellement plus de 20 000, répartis sur le site.
Exemple de bundle
Et ce qui est intéressant, c’est que cette approche varie complètement d’un type de produit à un autre :
Le résultat permet de répondre le mieux possible à l’intention de l’internaute.
Un autre point clé, c’est que les noms des produits sont déterminés automatiquement par le PIM.
Sur beaucoup de sites marchands, les titres sont remplis de mots-clés pour optimiser le ranking dans les algorithmes. On peut considérer ça comme du keyword stuffing.
![]()
Et sur une page de listing comme Geek Planet, c’est non seulement mauvais pour l’UX, mais aussi pas propre d’un point de vue SEO, parce que ça donne un rendu illisible et artificiel, en plus de diluer le vrai contenu qui est fait à la main.
Le fait de contrôler les titres permet d’avoir quelque chose de simple, cohérent, et plus qualitatif.
![]()
Au moment où j’écris ces lignes, on est en train de travailler sur la possibilité de filtrer et trier les blocs qui contiennent beaucoup de produits.
Et c’est un vrai challenge technique, vu la masse de données à traiter.
Mais c’est aussi ça qu’il faut retenir : un produit aussi complexe nécessite énormément d’itérations pour être parfaitement fonctionnel.
Tu ne peux pas obtenir, dès les premiers déploiements, un résultat qui répondra à tous les besoins. Mais c’est ce qui te permettra à terme, de distancer la concurrence en proposant un produit vraiment unique pour tes utilisateurs.
Geek Planet est bien plus qu’un simple « site d’affiliation » ou un simple « comparateur ».
C’est un produit tech, que nous avons construit autour de la donnée, pensé pour le SEO, mais surtout conçu pour apporter de la valeur réelle à l’utilisateur. Cette première partie est un socle technologique qui va permettre la création de tout un écosystème.
Et ce qui est le plus enthousiasmant, c’est de voir qu’à terme, toutes les pièces du puzzle se rejoignent aussi facilement : le PIM, les bundles, la segmentation, l’historique de prix, le SEO, l’UX.
Au début, tout semble un peu fragmenté. Mais avec le temps, les itérations, et les bons choix structurants, on finis par obtenir une base cohérente, équilibrée, et extrêmement difficile à reproduire tellement elle contient de détails.
Dans le prochain épisode, je vais te parler de comment l’équipe a été structuré pour pouvoir créer ce projet.
Mon pire échec (et ce que ça m'a appris)
Réservé aux personnes inscrites à la newsletter.
Gratuit & sans spam.
Déjà inscrit ? Accéder à la newsletter.
Cet article t'a plu ? Découvre le prochain épisode du Build in Public "#04 – L’évolution de l’équipe derrière Geek Planet"
Pour ne rater aucune publication, tu peux me suivre sur mes réseaux sociaux :