Quinze ans sur le même problème
ListoMax n'est pas né d'une étude de marché. Il est né d'une boutique vide qu'il fallait remplir, et de nuits passées à copier-coller des fiches produits.
2011 — une boutique à remplir
J'avais une boutique PrestaShop et une semaine pour la remplir. Deux cents produits à créer, la plupart déclinés en plusieurs coloris et plusieurs tailles. Chaque déclinaison devait devenir une fiche à part entière, avec sa référence, ses photos, sa description.
Au bout de deux jours, le calcul était clair : à ce rythme, j'y passerais un mois. J'ai arrêté de saisir et j'ai écrit un outil qui le ferait à ma place. Rustique, laid, sans interface digne de ce nom — mais il générait les fiches et les envoyait dans la boutique. La semaine a suffi.
Ce que ce premier outil m'a appris
Que le problème n'était pas la saisie en elle-même. C'était la répétition : le même produit ressaisi douze fois pour douze coloris, puis une fois de plus pour chaque boutique à alimenter. Un travail sans valeur ajoutée, qui prend les heures qu'on devrait passer à vendre.
Que les outils existants répondaient à côté. Les imports CSV natifs des CMS gèrent bien les gros volumes structurés, mais ils supposent que le fichier existe déjà et qu'il est propre. Ils n'aident pas à créer les déclinaisons, ni à remplir douze fiches à partir d'une seule, ni à servir deux boutiques à la fois.
Que la vraie difficulté était ailleurs que dans le principe : elle était dans les détails de chaque CMS. Un produit rangé dans une sous-catégorie qui n'apparaît nulle part parce que la catégorie parente n'a pas été rattachée. Un taux de TVA qui n'existe pas sur la boutique et qui fait partir le produit hors taxe. Une modification enregistrée qui ne remonte jamais en ligne. Chacun de ces pièges m'a coûté des heures.
2026 — ListoMax
ListoMax est cette idée de 2011, poussée jusqu'au bout. La fonction Série en est l'héritage direct : un formulaire rempli une fois, et autant de fiches complètes que de déclinaisons saisies.
Le reste s'est construit autour, au fil de ce que les boutiques réelles imposent. Les catégories parentes qu'il faut rattacher pour qu'un produit soit visible en navigation. Les taux de TVA qu'il faut lire sur la boutique plutôt que deviner. Les variantes qu'il ne faut pas casser en republiant. Les images qu'il faut vraiment téléverser. L'historique qu'il faut conserver pour pouvoir revenir en arrière.
Chaque fonction est validée sur de vraies boutiques avant d'être livrée : PrestaShop 8, PrestaShop 9, WooCommerce. Après chaque publication, le logiciel relit la fiche depuis la boutique pour vérifier qu'elle a bien reçu ce qui a été envoyé. C'est plus long à développer. C'est la seule manière de savoir que ça marche.
Le principe qui guide le développement
Jamais de panne silencieuse.
Un client qui utilise ListoMax ne peut pas ouvrir une console de développement pour comprendre ce qui s'est passé. Si quelque chose échoue, il doit le voir à l'écran, savoir quel produit est concerné et pourquoi. Une erreur affichée est réparable ; une erreur muette fait perdre des données sans que personne ne s'en aperçoive.
Ce principe a des conséquences concrètes. Une modification qui n'a pas pu être enregistrée doit le dire. Un taux de TVA introuvable doit bloquer la publication plutôt que la laisser passer avec un mauvais taux. Une image qui n'a pas été téléversée doit apparaître dans la liste des erreurs, pas disparaître dans le vide.
C'est le genre de détail qui ne se voit pas sur une page de vente. C'est pourtant ce qui fait la différence entre un outil qu'on utilise et un outil qu'on abandonne au bout de trois semaines.
Un projet indépendant
ListoMax n'est pas édité par une société qui vend dix autres logiciels. C'est un projet indépendant, développé et soutenu par la même personne. Quand vous écrivez au support, c'est cette personne qui répond.
Ce que ça change pour vous : les retours pèsent directement sur ce qui est développé ensuite. Une fonction demandée par plusieurs utilisateurs passe en tête de liste. Un bug signalé est corrigé dans la version suivante, pas dans deux ans.
Ce que ça change aussi : les délais dépendent d'une seule personne. Nous préférons l'annoncer que le laisser découvrir.
Ce qui est prévu
Sans dates promises : les délais dépendent d'une seule personne, et nous préférons livrer testé que livrer vite.
Shopify et BigCommerce
Les deux connexions sont développées. Elles seront activées quand elles auront été validées sur de vraies boutiques, selon le même protocole que PrestaShop et WooCommerce.
Version macOS
Prévue après la version Windows. Si vous travaillez sur Mac, dites-le nous : le nombre de demandes décide de la priorité.
Version Linux
Envisagée après macOS, si la demande existe. Écrivez-nous si c'est votre cas.
Le même problème que le vôtre
Si vous avez déjà passé une journée à créer des fiches produits à la main, vous savez de quoi il s'agit.