Outils internes et données
Tukassi Hub
Un fichier Excel partagé faisait vendre deux fois le même vêtement. Ce catalogue est devenu la seule source de vérité pour six plateformes de vente.
Le problème
Tukassi vend des vêtements de seconde main. Chaque pièce est unique : il n'existe qu'un seul exemplaire. Le stock était suivi dans un fichier Excel partagé, et les annonces étaient recopiées à la main sur plusieurs plateformes.
La conséquence était mécanique. Une pièce vendue sur une plateforme restait en ligne sur les autres. Un deuxième acheteur payait pour un article qui n'existait plus, et il fallait annuler, rembourser, s'excuser. Chaque vente en double coûte de l'argent, du temps, et un peu de réputation.
Ce que j'ai construit
Un catalogue unique d'environ 900 articles, avec un vrai schéma relationnel : les articles, leurs photos, les annonces publiées par plateforme, les ventes, et les réglages propres à chaque canal. Une pièce n'existe qu'une fois, et ses annonces pointent vers elle.
Par-dessus, un tableau de bord qui répond aux questions qu'on se pose vraiment : combien de chiffre d'affaires ce mois, quelle marge, combien vaut le stock qui dort, et combien de jours en moyenne entre la mise en ligne et la vente.
Et un panneau d'alertes, qui est la partie qui a réglé le problème d'origine : risque de vente en double, quota de cent annonces atteint sur Ricardo, articles dormants depuis trop longtemps, articles sans photo ou sans prix.
Les choix techniques
Le modèle de données passe avant l'interface. Une annonce est une ligne reliée à un article et à une plateforme, jamais une copie de l'article — c'est ce qui rend la détection des doubles possible sans aucune heuristique.
Les indicateurs sont calculés à partir des ventes enregistrées, pas d'un compteur qu'on incrémente. Un compteur finit toujours par diverger de la réalité ; un calcul, non.
PostgreSQL via Supabase, interface en TypeScript et React.
Ce que j'en retire
C'est le projet qui m'a appris qu'un problème présenté comme « il faudrait un outil » est presque toujours un problème de modèle de données. Le tableau de bord est la partie visible ; ce qui a réglé les ventes en double, c'est d'avoir arrêté de dupliquer l'information.
Chiffres à compléter avant candidature : date de mise en service, nombre de ventes en double avant et après, temps gagné par semaine sur la gestion des annonces.
Application privée — je la montre volontiers en entretien.