Ce que construire un produit seule m'a appris sur les projets clients
Depuis fin 2025, je construis seule LudoExplorer, un site de recommandation de jeux de société, depuis un export de données publiques jusqu'à un serveur en production. J'ai raconté ce qui a mal tourné et ce que j'en ai appris dans une série de dix articles sur Medium, en anglais. Ces articles sont techniques. Ici je ne vais que vous exposer les six leçons qui valent aussi pour un projet client, qu'il y ait du code ou non.
Décider à quoi servent les données avant de les nettoyer
L'export public dont je suis partie contenait environ 125 000 entrées. Il répondait à la question de ce que la source recense. Mes visiteurs en posent une autre : à quoi pourrais-je jouer ? Les objets promotionnels, les bonus de campagnes de financement participatif et les éditions en double n'avaient pas leur place dans la réponse. Le catalogue du site garde environ 90 000 jeux.
Avant de nettoyer quoi que ce soit, j'ai rédigé un dictionnaire de données : une ligne par colonne, avec ce qu'elle signifie, la transformation à lui appliquer et si elle peut être modifiée. Cela m'a pris un après-midi, et ce document a ensuite piloté l'outil d'édition que j'ai construit pour ces données.
Il en va de même pour un export de CRM ou un fichier produits. « Tout ce qui se trouve dans l'export » n'est pas un besoin. Partez de ce que l'utilisateur attend des données, et filtrez en fonction de cela.
Lire la partie 1 sur Medium (en anglais) : I broke my own dataset
Les libellés font partie de l'interface
La source décrit chaque jeu par des libellés. L'un des types, les familles, compte 5 295 valeurs. Catan en porte 17 à lui seul, et 3 seulement disent de quoi parle le jeu. Les autres intéressent un collectionneur et encombrent la personne qui choisit un jeu pour samedi soir.
J'ai construit ma propre classification par-dessus, avec des groupes larges pour parcourir et des libellés précis pour le détail. Il a fallu plusieurs corrections. Mes premières règles par mots-clés ont rangé un feuilleton télévisé dans un groupe consacré à l'expérience de jeu. Un groupe qui ne contenait qu'une option paraissait étrange à l'écran, alors que la donnée était correcte. Deux éléments qui portaient le même nom passaient pour la même chose.
Les catégories, les statuts et les types de produits d'un outil de gestion fonctionnent de la même façon. Les gens les lisent comme une partie de l'écran. Classez selon la manière dont vos utilisateurs cherchent, et relisez le résultat groupe par groupe.
Lire la partie 2 sur Medium (en anglais) : 5,295 families and no themes
Quand on ne peut pas deviner ce que quelqu'un veut, le lui demander
Dans le même champ de recherche, les visiteurs saisissent deux choses différentes : le nom d'un jeu, ou une idée, par exemple un jeu coopératif avec des animaux pour quatre joueurs. Pendant des mois, j'ai essayé de détecter automatiquement de quel cas il s'agissait. Chaque règle que j'écrivais cassait un autre cas.
J'ai fini par arrêter de deviner. La page de recherche propose maintenant deux modes, l'un pour trouver un jeu par son nom, l'autre pour explorer à partir d'une idée. Elle affiche aussi ce qu'elle a compris de la question, pour que le visiteur puisse corriger.
Je connais cette règle par l'analyse business, et j'ai pourtant dû la réapprendre sur mon propre projet. Quand un besoin ne se déduit pas de façon fiable, une question simple vaut mieux qu'une supposition habile.
Lire la partie 5 sur Medium (en anglais) : A game or an idea? Building search in three languages
Compter ce que les gens font, pas les pages chargées
J'ai construit mes propres statistiques de visite pour le site. Sur les quatre premières semaines de septembre 2026, elles ont compté 259 106 sessions. Seules 136 contenaient une action au-delà du chargement d'une page, comme une recherche, un filtre ou un clic sur un jeu. Presque tout le reste se résumait à un seul chargement de page, très probablement du trafic automatisé.
Le premier chiffre ressemblait à un site en pleine croissance. Le second est plus proche de la réalité, et il n'a rien d'étonnant pour un site dont je n'ai pas encore fait la promotion. Ce qui m'a surprise, c'est à quel point le premier chiffre était convaincant.
Avant qu'un tableau de bord n'oriente une décision, définissez ce qu'est un vrai visiteur ou une vraie action client, et comptez cela. Jusqu'ici, mes statistiques m'ont surtout servi à repérer des erreurs, pas à orienter le produit, et je préfère le dire.
Dès que des gens l'utilisent, arrêter de tout reconstruire
Au début, chaque mise à jour des données reconstruisait toute la base à partir du fichier source. Cela convenait tant que la base ne contenait que le catalogue. Dès qu'elle a aussi contenu des données de visite et des messages de contact, une reconstruction les aurait effacés sans retour possible.
J'ai construit un chemin de mise à jour qui modifie le catalogue et ne touche à rien d'autre, avec un essai à blanc qui annonce ce qui changerait avant toute écriture. J'ai ajouté des sauvegardes chaque nuit, stockées ailleurs, et des procédures écrites pour les opérations que je fais moins d'une fois par semaine.
En tant qu'analyste, je rédige ce genre de document pour mes clients. Sur mon propre projet, j'y ai d'abord résisté, parce que je connaissais le système. Six mois plus tard, je ne le connaissais plus avec le niveau de détail qu'exige une opération en production.
Lire la partie 3 sur Medium (en anglais) : A 300 MB database that needed 2 GB to build
Lire la partie 9 sur Medium (en anglais) : One server, 7 euros a month
Un assistant IA rend les besoins clairs plus importants
J'ai travaillé avec un assistant de programmation IA tout au long du projet. Il m'a surtout aidée pour la documentation et pour exposer les options afin que je décide. Il savait aussi défendre de façon convaincante une conclusion fausse.
Une revue qu'il avait rédigée proposait un correctif qui semblait tenir en une ligne. J'ai mesuré avant d'agir. Le correctif aurait réécrit 5 441 clés de recherche correctes dans un format que la recherche n'aurait jamais retrouvé, et effacé 147 termes de recherche que j'avais écrits à la main. Il n'a pas été appliqué.
Un assistant agit sur ce que vous écrivez, vite et au pied de la lettre. Cerner le besoin et le formuler avec précision, ce qui est le cœur de l'analyse business, s'est révélé être ce qui rendait l'assistant utile. Et la règle vaut pour toute explication, les miennes comprises : mesurer avant de croire.
Lire la partie 10 sur Medium (en anglais) : From debugger to project partner
La série complète
Les dix parties couvrent aussi les modèles de recommandation, l'application elle-même, la visibilité dans les moteurs de recherche et l'hébergement. La liste complète se trouve sur la page du projet LudoExplorer, et le site lui-même sur ludoexplorer.com.
Aucune de ces leçons ne concerne les jeux de société. Elles portent sur le fait de savoir à quoi servent les données, de nommer les choses comme le font les utilisateurs, de demander plutôt que deviner, de mesurer honnêtement, de protéger ce qui fonctionne déjà et de formuler le besoin clairement. Un projet personnel m'a fait payer moi-même le prix de chacune.
À lire aussi
-
Analyse business
Pourquoi un cahier des charges clair fait gagner du temps à toute l'équipe, pas seulement à l'informatique
Un cahier des charges est souvent vu comme un document technique, destiné surtout à l'équipe qui va développer la solution.
-
Analyse business
Choisir un CRM : 5 questions à se poser avant de comparer les outils
Comparer des CRM sur leurs fonctionnalités est une étape qui arrive trop tôt dans la plupart des projets.
-
Analyse business
Ce qui distingue un bon user story d'un mauvais, avec des exemples concrets
Le user story est devenu un format courant pour décrire un besoin dans un projet digital.
Ce qu'un projet personnel apprend à ses dépens vaut aussi pour un projet client
Si votre projet bute sur l'un de ces points, je peux vous aider à clarifier le besoin avant de choisir une solution.

