Connecter PrestaShop à GoManage et Aunabase : un cas réel

Vingt-trois heures. Un installateur ouvre la boutique sur son téléphone, ajoute trois mètres de goulotte, une boîte d'appareillage et un différentiel, et paie. Le lendemain matin, au dépôt, il ne restait qu'une boîte : les deux autres sont parties au comptoir vendredi à dix-huit heures trente.

Le client n'a rien fait de mal, la boutique non plus. Le souci, c'est que la boutique et le dépôt vivent à deux endroits différents — le site d'un côté, l'ERP de l'autre — et qu'entre les deux il y a quelqu'un qui recopie les prix et les stocks quand il a un moment.

Voici ce que nous avons monté pour un distributeur de matériel électrique et de plomberie qui travaille avec deux outils très connus du secteur : Go!Manage, l'ERP de Telematel, et Aunabase, la base de données produit du groupe Aúna Distribución.

Le point de départ : deux systèmes qui fonctionnaient déjà

L'entreprise n'avait pas de problème de logiciel. Son ERP était à jour, avec près de trente mille articles enregistrés, ses tarifs et son stock par dépôt. Et elle avait accès à Aunabase, là où les fabricants du groupe déposent les bonnes fiches : le vrai nom commercial, la description technique, les photos, le code-barres, la marque, l'unité de vente de chaque référence.

Ce qu'elle n'avait pas, c'était une boutique. Et la tentation, quand on en monte une, c'est de la remplir à la main : exporter un tableur, l'importer, retoucher, et se retrouver trois mois plus tard avec un troisième catalogue qui ne ressemble à aucun des deux autres.

La boutique n'est pas un endroit de plus où stocker le catalogue. C'est la vitrine de ce qui est déjà dans l'ERP.

Avec cette idée, le travail a cessé d'être « rentrer les produits dans PrestaShop » pour devenir quelque chose de bien plus simple à expliquer : décider qui commande sur quoi.

Qui commande sur quoi

Tout le projet tient sur ce partage, et c'est la partie à trancher avant de toucher à quoi que ce soit :

• L'ERP commande sur le commerce. Quelles références sont vendues, à quel prix, combien il en reste et lesquelles sont en tarif promotionnel. Rien de tout cela ne se modifie depuis la boutique.
• Aunabase commande sur la façon de présenter le produit. Nom, description, images, marque, fabricant, code-barres, famille et unité de vente minimale.
• La boutique commande sur la vente. La page d'accueil, les campagnes, ses propres textes, les expéditions et la relation client.

Sur les presque trente mille articles de l'ERP, la boutique en présente une sélection de 16 700 références : celles que le distributeur veut vendre en ligne. Les autres restent dans l'ERP et n'apparaissent pas. Élargir ou réduire cette liste est une décision commerciale prise dans l'ERP, pas une tâche de maintenance du site.

Ce que voit le client

Au quotidien, une fois en place, la boutique se comporte comme ceci :

• Des fiches compréhensibles. Chaque produit arrive avec son nom commercial, sa description technique, ses photos et sa marque, et non un « REF 4021 BLANC » avec une image générique. C'est ce qui permet à la fiche d'exister sur Google, d'où vient la moitié des visiteurs — nous l'expliquions dans par où commencer quand votre boutique n'apparaît pas.
• Des prix et des stocks qui sont ceux du dépôt. Pas ceux du dernier export.
• Sans stock, pas de vente. La référence reste visible — on veut que Google la connaisse et que le client sache que vous la travaillez — mais elle ne peut pas être mise au panier tant qu'il n'y a pas d'unités.
• Chaque chose dans son unité. Si une référence se sert par boîtes de dix, la boutique n'en laisse pas commander sept. L'unité minimale vient de la fiche du fabricant : la commande arrive prête à préparer.
• Les fins de série disparaissent seules. Quand une référence est retirée, elle cesse d'être en vente sans que personne ait à y penser.
• Les promotions se rangent seules. Ce qui est en tarif promotionnel dans l'ERP atterrit dans la catégorie promotions de la boutique, et en ressort tout aussi discrètement quand le tarif change.

Personne n'entretient tout cela. C'est la même information déjà tenue à jour dans l'ERP et dans Aunabase, vue depuis le web.

Et la commande, au retour

La moitié intéressante d'une intégration est celle qui va dans l'autre sens. Quand le client paie, la commande entre dans Go!Manage avec ses lignes, ses quantités, l'adresse de livraison, celle de facturation et le mode de paiement traduit dans celui que l'ERP comprend. Personne ne la ressaisit.

Et comme cela doit être vérifiable, la fiche de commande du back-office indique si elle est bien arrivée dans l'ERP, avec un bouton pour la renvoyer. C'est le vrai changement pour l'entreprise : fini le « je la passerai dans l'ERP dès que je peux ». Le dépôt voit la commande là où il voit toutes les autres.

Les trois décisions qui font que ça tient

Une intégration se juge au bout de six mois, pas le jour où on l'allume. Voici les trois qui évitent les problèmes classiques :

1. Le prix et le stock ne se modifient qu'à un seul endroit. Dans l'ERP. Une boutique où l'on peut aussi les changer à la main finit par se contredire, et la contradiction tombe toujours le jour de la plus grosse journée.
2. Ce qui est écrit à la main n'est jamais écrasé. Quand quelqu'un améliore un nom de produit, réécrit une description ou charge une meilleure photo, la mise à jour suivante respecte ce travail. Sans cette règle, plus personne ne retouche une fiche.
3. La mise à jour avance par lots et sait reprendre. Un catalogue de cette taille ne se rafraîchit pas d'un seul coup : il se traite par blocs et, s'il est interrompu, il repart où il en était. La boutique n'a jamais à fermer « pour maintenance » ni à rester avec un catalogue à moitié fait.

Ce dont nous avons besoin de votre côté

Quand on nous interroge là-dessus, ce que nous devons savoir tient en peu de choses :

• Un utilisateur de connexion à votre Go!Manage, fourni par votre prestataire ERP.
• Vos identifiants Aunabase, si vous êtes une entreprise associée au groupe.
• La sélection de références que vous voulez vendre en ligne et la façon de les regrouper en familles.
• Et une décision commerciale : vendre aux professionnels à prix négociés, ouvrir au grand public, ou les deux à la fois. Nous en parlons à part, dans comment ne montrer le catalogue qu'aux clients validés.

Avec cela, on peut déjà lancer un premier passage d'essai et regarder le vrai catalogue dans la boutique avant de décider quoi que ce soit d'autre.

Si vous travaillez avec Go!Manage ou Aunabase

Nous connaissons les deux de l'intérieur et nous savons où ça coince d'habitude : les références en double dans l'ERP, les familles qui ne correspondent pas à la façon dont le client achète, les produits sans photo, les tarifs spéciaux. Rien de tout cela n'est rare et rien n'empêche de sortir en ligne.

Et si votre ERP est un autre, l'approche reste la même : l'ERP commande sur le prix et le stock, le bon catalogue commande sur les fiches, et les commandes reviennent toutes seules.

Votre ERP est à jour et la boutique reste à faire ? Dites-nous ce que vous utilisez et nous vous dirons ce qui peut être connecté, et dans quel ordre.

Parlez-nous de votre cas