Partir d'une commande représentative
Prenons un exemple fictif : un revendeur achète plusieurs tailles d'un produit, puis ajoute des références de deux autres gammes. Pour les tailles d'un même produit, une grille sur la fiche peut suffire. Pour plusieurs références, un écran de commande rapide peut être plus adapté.
Le choix dépend aussi des informations nécessaires avant l'achat : image, référence, conditionnement, disponibilité ou prix. Décrivez d’abord si le client sélectionne les variantes d’un seul produit ou plusieurs références : ce sont deux parcours différents.
Configuration, module existant ou développement spécifique ?
Commencez par vérifier ce que votre boutique sait déjà faire. Le mode B2B décrit par PrestaShop (nouvel onglet) ajoute notamment des informations professionnelles aux fiches clients. Son activation ne suffit pas à décrire un parcours de commande adapté à vos revendeurs : il faut encore préciser leurs accès, leurs tarifs et leur manière de commander.
Un paramétrage peut suffire lorsque le besoin correspond aux fonctions disponibles et que les essais sur vos profils et produits donnent le résultat attendu. Faites cet inventaire avant de commander un développement.
Un module existant mérite d’être examiné pour un usage courant : saisie de références, import d’une liste ou espace réservé aux professionnels. Comparez son périmètre documenté à votre commande type, puis vérifiez sa version, ses dépendances, son thème et ses conditions de maintenance. Une liste de fonctions ne prouve pas qu’elles fonctionnent ensemble sur votre boutique.
Une adaptation est à envisager si une solution couvre l’essentiel mais laisse une règle précise sans réponse. Faites nommer cette différence, le moyen de l’intégrer et ce qui devra être revérifié lors des mises à jour. L’adaptation n’est pas toujours possible ni préférable.
Un développement spécifique se justifie par un écart concret : un enchaînement métier, un contrôle ou un échange de données que les solutions examinées ne couvrent pas convenablement. Il demande lui aussi une maintenance et des tests. Le choix doit inclure le coût d’intégration, de reprise et de suivi, pas seulement le prix initial du module.
Par exemple, un revendeur qui connaît ses références peut souhaiter importer sa liste. Un autre doit comparer les variantes avant de choisir. Ce sont des exemples fictifs : ils servent à préciser le besoin, pas à affirmer que votre boutique nécessite du sur mesure.
Écrire les règles qui doivent rester vraies
| Sujet | Question à trancher avant réalisation |
|---|---|
| Accès | Quels clients voient quels produits et peuvent commander ? |
| Prix | Quel tarif s'applique à chaque groupe, quantité ou variante ? |
| Affichage | Quelles informations HT/TTC sont attendues selon le contexte ? |
| Quantités | Existe-t-il un minimum, un multiple ou un conditionnement ? |
| Disponibilité | Que devient une ligne dont la quantité ne peut être servie ? |
| Validation | La commande est-elle directe ou soumise à une étape métier ? |
| Suite du parcours | Quels outils et quelles personnes traitent la commande ? |
Ces questions constituent un cahier de cadrage. Elles ne signifient pas que toutes ces fonctions sont incluses dans une démonstration ou disponibles sans adaptation.
Examiner les réalisations à leur juste portée
La commande rapide Wolyus illustre la sélection de plusieurs références et un résultat d’ajout par ligne. Sa version 1.0.0 a une recette documentée du 23 octobre 2026 sur PrestaShop 9.1.5 avec le thème Classic. Cette recette n’a pas été rejouée pour ce guide.
Cette démonstration dépend du module Panier Wolyus et de JavaScript ; la page de réalisation détaille les limites. Elle ne prouve ni import CSV, ni portail B2B complet, ni connexion ERP, ni compatibilité avec votre thème ou le multiboutique. Elle permet de discuter d’un parcours concret avant de décider ce qui doit être conservé, configuré ou développé.
Définir une recette avec des cas de refus
Préparez quelques produits et profils représentatifs dans un environnement de test. Jouez une commande autorisée, une quantité insuffisante, un accès refusé et une sélection dont une seule ligne peut être ajoutée. Comparez le résultat affiché au contenu réel du panier.
Si le parcours communique avec un autre outil, précisez quelle donnée fait référence, comment une erreur est repérée et qui peut la traiter. Une interface fluide ne suffit pas à établir que la commande est correctement reprise ailleurs.
Le guide de vérification du panier propose une méthode pour décrire les résultats attendus sans se limiter au nombre de clics.
Préparer votre demande
Décrivez une commande type, les différences entre vos clients et les règles de prix ou de quantité qui comptent. Mentionnez les outils connectés et les fonctions déjà présentes. Le cadrage pourra distinguer configuration, adaptation d'un module et développement spécifique.
Une liste courte pour préparer le premier échange
- Une commande représentative, sans coordonnées de client.
- Les différences de prix, d’accès et de quantités qui doivent être respectées.
- Les modules déjà présents, la version de PrestaShop et le thème si vous les connaissez.
- Les informations qui doivent rejoindre un autre outil et la personne qui vérifie leur réception.
- Un résultat attendu et un cas où l’ajout doit être refusé.
Vous pouvez commencer par décrire votre situation ; cette liste ne vous oblige pas à produire un cahier des charges technique avant le premier échange.