# Développement e-commerce pour l’industrie et les équipements techniques

> Sur une boutique industrielle, le catalogue n’est pas le patrimoine du site : il appartient à l’ERP. La boutique est une façade de commande, et presque toutes les difficultés du projet découlent de cette répartition des rôles.

- Source canonique : [https://allaux.fr/secteurs/industrie-equipements-techniques](https://allaux.fr/secteurs/industrie-equipements-techniques)
- Langue : FR
- Dernière mise à jour : 2026-07-26

## La boutique n’est pas le référentiel article

Le prix, le stock, l’encours et la fiche client vivent dans l’ERP. La boutique en affiche une copie et y renvoie des commandes. Poser cela clairement change tout le reste : la question à trancher avant la première ligne de code est celle du sens de la synchronisation, champ par champ, et de l’arbitre en cas de désaccord entre les deux systèmes sur une même donnée.

Cette décision se prend par écrit, avec les personnes qui utilisent l’ERP au quotidien, et non au premier conflit constaté en production. Un tableau qui indique, pour chaque champ, qui écrit et qui lit, évite la situation classique où une correction faite côté boutique est écrasée à la synchronisation suivante — et où plus personne ne sait quelle valeur est la bonne.

## Symptômes d’une répartition des rôles jamais tranchée

- Une correction de prix saisie dans la boutique disparaît à la synchronisation suivante, sans trace ni alerte.
- Une date de disponibilité annoncée par le site est démentie par l’ERP au moment de la préparation.
- Le même article existe sous deux codes différents parce que la codification a été refaite à la main côté boutique.
- Les tarifs négociés ne descendent pas jusqu’au panier : le client identifié voit le prix public.
- La documentation technique est un dossier de fichiers déposés sur le serveur, sans version ni rattachement à une référence.
- Le pas de quantité imposé n’est pas contrôlé : une commande arrive avec une quantité que la production ne sait pas fabriquer.
- La commande ne produit qu’un PDF, sans données structurées exploitables par le système de facturation.

## Codification, documents et conditionnements

Une référence industrielle se définit par une combinaison de caractéristiques physiques : matière, diamètre, longueur, filetage, traitement de surface. Le code article se calcule à partir de ces caractéristiques plutôt qu’il ne se choisit. La fiche doit donc permettre de descendre jusqu’à la variante exacte à partir de ces critères, sans produire des centaines de pages presque identiques qui se cannibalisent entre elles.

Le client industriel cherche souvent le document avant le produit. Plans, fiches techniques, certificats matière, notices multilingues, procès-verbaux d’essai : ces pièces doivent être versionnées, rattachées à la référence, parfois réservées aux comptes identifiés, et surtout trouvables par le moteur de recherche interne. Un document que la recherche ne renvoie pas est un document qui n’existe pas pour l’acheteur.

Restent les conditionnements et les délais. Vente par lot, quantité minimale de commande, pas de quantité imposé, délai d’approvisionnement propre à chaque référence, articles fabriqués à la commande : ce sont des règles portées par l’article, contrôlées dans le panier, et non des mentions décoratives. Une date de disponibilité annoncée puis démentie coûte plus cher qu’une absence de date.

## Ce que je pose avant de développer

1. **Le tableau des champs et de leur propriétaire** — Pour chaque donnée — prix, stock, délai, code article, coordonnées client — qui écrit, qui lit, à quelle fréquence, et qui l’emporte en cas de conflit. Ce document sert ensuite de référence quand un écart apparaît.
2. **La règle de calcul du code article** — La codification se déduit des caractéristiques. Je la formalise pour qu’un nouvel article importé reçoive automatiquement le bon code, plutôt que de dépendre d’une saisie qui finira par diverger.
3. **Le comportement du prix non public** — Beaucoup de références n’ont pas de prix affiché. Le catalogue doit savoir masquer un montant, afficher une mention sur demande, et déclencher une demande de devis qui atterrit dans l’outil du commercial avec le contexte du panier.
4. **La sortie de commande en données structurées** — Identifiants de l’acheteur, référence de commande et de marché, mentions obligatoires : je vérifie dès le cadrage que la commande produit autre chose qu’un document imprimable, parce que cela conditionne toute la chaîne de facturation.

## Interventions liées

- **Intégration d’API fournisseurs B2B** — Relier un catalogue à des fournisseurs ou à une marketplace professionnelle et tenir la synchronisation dans la durée. ([/expertises/integration-api-fournisseurs-b2b](/expertises/integration-api-fournisseurs-b2b))
- **Connecter PrestaShop à un ERP** — Les points de friction habituels quand la boutique et l’ERP doivent partager articles, stocks et commandes. ([/prestashop/problemes/connecter-erp-fournisseur-api](/prestashop/problemes/connecter-erp-fournisseur-api))
- **Connecter Shopify à un ERP** — Les contraintes propres à une plateforme hébergée quand le référentiel reste hors de la boutique. ([/shopify/problemes/connecter-shopify-erp](/shopify/problemes/connecter-shopify-erp))
- **Devis PDF automatisé** — Transformer un panier en devis exploitable par le commercial, sans ressaisie. ([/realisations/devis-pdf-automatise](/realisations/devis-pdf-automatise))

## Facturation électronique : cela se prépare en amont du tunnel

> La généralisation de la facturation électronique entre entreprises impose que la commande produise des données structurées exploitables, et pas seulement un document imprimable : identifiants de l’acheteur, références de commande et de marché, mentions obligatoires. Ce sont des champs à collecter dans le tunnel et à conserver correctement typés. Les ajouter après coup revient à reprendre le passage de commande, le modèle de données et l’historique déjà enregistré.

## FAQ

### Faut-il synchroniser la boutique et l’ERP dans les deux sens ?

Rarement pour tous les champs. Le plus souvent l’ERP écrit le prix, le stock et le délai, tandis que la boutique écrit les commandes et parfois les coordonnées de livraison. Décider champ par champ évite les écrasements silencieux et simplifie beaucoup le développement.

### Comment éviter des centaines de pages presque identiques pour une même famille ?

En publiant une page par famille technique, avec un sélecteur qui descend jusqu’à la variante exacte à partir des caractéristiques : matière, diamètre, longueur, filetage. La variante reste commandable et identifiée, sans être une page indexable de plus.

### Peut-on afficher des tarifs différents selon le client ?

Oui, à condition que la grille tarifaire vienne de l’ERP et soit appliquée après identification, par client et par famille de produits. Il faut aussi prévoir le cas du visiteur non identifié, qui ne doit voir ni le prix négocié ni l’encours.

### Où stocker plans et certificats matière ?

Rattachés à la référence, avec un numéro de version et une date, et une règle d’accès distinguant ce qui est public de ce qui est réservé aux comptes identifiés. Le moteur de recherche interne doit indexer leurs métadonnées, sinon l’acheteur ne les trouve pas.

### Comment gérer un délai d’approvisionnement propre à chaque référence ?

Comme une donnée article venant de l’ERP, recalculée dans le panier en fonction de la ligne la plus longue, et affichée avec sa nature : stock disponible, réapprovisionnement, ou fabrication à la commande. Mieux vaut ne rien annoncer que d’annoncer une date fausse.

### Que faire des articles vendus par lot ou avec un pas de quantité ?

Le contrôle doit se faire dans le panier et non par un simple message d’information : quantité minimale, multiple imposé, arrondi automatique à la valeur commandable la plus proche. Sinon la commande arrive avec une quantité que la production ne sait pas honorer.