Stack technique e-commerce : une stack de référence pour chaque taille de boutique

Une stack technique e-commerce est l'ensemble des systèmes qui font tourner une boutique en ligne : la plateforme e-commerce et les paiements au centre, et autour d'eux les outils pour l'information produit (PIM), les ressources numériques (DAM), la recherche sur le site, le stock et les commandes (ERP ou OMS), l'expédition, l'analytics, l'e-mail, les avis et les feeds de canaux. Chaque système doit être propriétaire d'un seul type de donnée, et la stack fonctionne quand tous les autres systèmes lisent cette donnée au lieu d'en garder leur propre copie.

La réponse courte sur ce qu'il faut acheter : une boutique avec un seul canal et quelques centaines de produits a besoin d'une plateforme, des paiements, de l'analytics, d'un outil d'e-mail et d'une app d'avis, et de pas grand-chose d'autre. Un PIM se justifie quand le catalogue, le nombre de canaux ou le nombre de langues dépasse ce que gère l'admin de la plateforme. Un ERP ou un OMS se justifie quand le stock, les achats et la finance s'étendent sur plusieurs sites ou canaux de vente. Tu trouveras ci-dessous trois stacks de référence selon la taille de la boutique, les flux de données entre les systèmes et un ordre d'achat basé sur l'endroit où la douleur apparaît en premier.

Onze systèmes d'une stack e-commerce et la donnée dont chacun est propriétaire

La plupart des guides sur les stacks listent des catégories d'outils. La question la plus utile est de savoir de quelle donnée chaque couche est la source de vérité, car c'est ce qui décide où une modification doit être faite.

• Plateforme e-commerce (Shopify, WooCommerce, Magento, Lightspeed, CCV Shop) : vitrine, panier, checkout et la commande telle qu'elle est passée.
• Paiements : la transaction, les remboursements et les versements.
• PIM (gestion de l'information produit) : le contenu produit : titres, descriptions, attributs, catégories, traductions et variantes de tout cela propres à chaque canal. Consulte ce qu'est un PIM pour la définition complète.
• DAM (gestion des ressources numériques) : images maîtres, vidéos, manuels ainsi que leurs droits et versions. Les petites boutiques gardent leurs ressources dans le PIM ou la plateforme ; le guide PIM vs DAM explique quand les séparer.
• Recherche sur le site et merchandising : l'index de recherche, les synonymes, les règles de classement et les produits mis en avant. Il lit les données produit sans en être propriétaire.
• ERP et OMS : niveaux de stock, bons de commande, prix de revient, factures et routage d'une commande vers un entrepôt ou un magasin. Le guide PIM vs ERP explique la frontière.
• Expédition et fulfillment : étiquettes, choix du transporteur, suivi et retours, dans une app d'expédition, chez un prestataire logistique (3PL) ou dans le système de l'entrepôt. Il lit la commande ainsi que le poids et les dimensions du produit.
• Analytics : les événements (vues, ajouts au panier, achats) et les rapports construits dessus, en général GA4 plus les rapports propres à la plateforme.
• E-mail et SMS : consentement, segments et messages envoyés aux clients.
• Avis : notes et textes d'avis rédigés par les clients, qui alimentent les fiches produit, les données structurées et les annonces Shopping.
• Feeds et connecteurs de canaux : la version de chaque produit que reçoit Google Shopping, Meta ou une marketplace, mappée sur les attributs de ce canal.

Une seule source de vérité par champ : prix, stock, contenu, consentement

Les conflits dans une stack portent presque toujours sur un champ revendiqué par deux systèmes. Décide de ces propriétaires sur papier avant de connecter quoi que ce soit :

Le coût d'une erreur se voit chez les acheteurs. Dans l'étude consommateurs 2025 de Salsify, 54 % des acheteurs ont déclaré avoir abandonné un achat à cause d'informations contradictoires. Des informations contradictoires, c'est ce que tu obtiens quand une description produit est modifiée dans la boutique, dans le PIM et dans l'outil de feed, et que chaque copie dérive.

Comment les données produit, commande et stock circulent entre les systèmes

Dessine la stack sous forme de flux, pas de boîtes. Quatre flux couvrent la plupart des boutiques :

Données produit : du fournisseur au PIM puis à chaque canal

1. Les fichiers fournisseurs, les données article de l'ERP ou les pages fabricant récupérées arrivent dans le PIM.
2. Le PIM comble les manques (attributs, descriptions, traductions), vérifie la fiche par rapport aux règles de chaque canal et la catégorise.
3. Le PIM pousse la fiche vers la plateforme et génère les feeds de canaux. La spécification des données produit de Google montre pourquoi la version du feed diffère de celle de la boutique : les titres sont limités à 150 caractères, les descriptions à 5 000, et des champs comme `gtin`, `brand`, `color` et `size` sont obligatoires selon le type de produit et le pays.
4. Les outils de recherche, d'avis et d'e-mail lisent les données produit depuis la plateforme ou un feed, jamais depuis un tableur envoyé par e-mail.

Commandes : du checkout au fulfillment et retour

1. La plateforme crée la commande et encaisse le paiement.
2. L'OMS ou l'ERP la récupère, réserve le stock et l'envoie vers un entrepôt.
3. Le statut d'expédition et le suivi reviennent à la plateforme, qui informe le client.
4. Les remboursements démarrent dans la plateforme ou l'OMS et sont comptabilisés dans l'ERP.

Stock : un seul chiffre, de nombreux affichages

Le stock part de l'ERP ou du système de l'entrepôt vers la plateforme et chaque marketplace, selon un planning ou à chaque changement. Plus la synchronisation est serrée, moins il y a de survente. Les marketplaces sanctionnent les annulations plus durement que ta propre boutique, donc le stock marketplace se synchronise en général plus souvent ou avec une marge de sécurité.

Analytics : des événements aux rapports puis à un data warehouse

La vitrine envoie des événements à GA4 ; la plateforme conserve la commande. Combine-les quand tu as besoin d'une analyse de marge ou au niveau produit. Une propriété GA4 standard peut exporter jusqu'à 1 million d'événements par jour vers BigQuery dans l'export quotidien, selon la documentation de Google, ce qui suffit à la plupart des boutiques de taille moyenne avant d'avoir besoin de quelque chose de plus lourd. Notre comparatif des outils d'analytics e-commerce classe les options selon la tâche qu'elles remplissent.

Stack de référence 1 : une boutique débutante de moins de 500 SKU sur un seul canal

Fais tourner tout ce que tu peux dans la plateforme. Chaque outil supplémentaire, c'est un identifiant de plus, une facture de plus et un endroit de plus où les données peuvent dériver.

• Plateforme et paiements : une plateforme hébergée avec paiements intégrés, comme Shopify avec Shopify Payments, ou WooCommerce avec un plugin de paiement.
• Données produit : l'admin de la plateforme plus un export CSV propre comme sauvegarde. Une offre PIM gratuite devient intéressante dès que tu traduis ou vends sur un deuxième canal.
• Recherche : la recherche intégrée de la plateforme. Corrige les données produit et les synonymes avant de payer un moteur de recherche séparé.
• Analytics : GA4 et Google Search Console, plus les rapports de vente de la plateforme.
• E-mail : un seul outil d'e-mail avec un flux de panier abandonné et une série de bienvenue.
• Expédition : les étiquettes d'expédition de la plateforme ou une seule app d'expédition avec suivi et page de retours.
• Avis : une seule app d'avis qui affiche les données d'avis sur les fiches produit ; Google peut afficher les notes à partir des données structurées produit.
• Feeds : l'app de canal Google de la plateforme.

Ce que tu peux laisser de côté à ce stade : ERP, DAM, moteur de recherche séparé, front-ends headless et middleware.

Stack de référence 2 : une marque en croissance avec 500 à 10 000 SKU et plusieurs canaux

C'est à ce stade que l'admin de la plateforme cesse d'être une source de vérité viable. Les produits vivent désormais dans la boutique, sur une ou deux marketplaces, dans Google Shopping et peut-être dans une boutique en deuxième langue, et chaque copie est modifiée séparément si rien de central n'en est propriétaire.

• PIM : le premier ajout majeur. Une seule fiche produit, enrichie une fois, poussée vers chaque canal avec des titres et attributs propres au canal.
• Gestion des feeds : dans le PIM ou dans un outil de feed dédié, avec des règles par canal pour les titres, les catégories et les exclusions.
• Ressources : une médiathèque structurée dans le PIM, avec des images nommées et liées aux SKU. Un DAM séparé est rarement nécessaire à ce stade.
• Inventaire : un outil d'inventaire ou un ERP léger dès que tu vends depuis plus d'un emplacement de stock ou d'un canal.
• Recherche : une app de recherche dédiée si le catalogue compte beaucoup d'attributs et de filtres.
• Analytics : GA4 plus les données de commande combinées au niveau produit, pour voir le chiffre d'affaires et la marge par produit et par canal.
• E-mail et avis : des flux segmentés par catégorie de produit ; des avis syndiqués vers Google.

Stack de référence 3 : un retailer ou grossiste multi-pays avec plus de 10 000 SKU

À cette taille, la stack compte plus de systèmes que de personnes qui les comprennent tous, donc la conception des intégrations compte autant que le choix des outils.

• ERP : propriétaire des articles, des coûts, du stock, des achats et de la finance. Les données de référence article naissent ici, puis le PIM ajoute le contenu.
• OMS : route les commandes entre entrepôts, magasins et dropshippers, et gère les expéditions fractionnées et les retours.
• PIM : contenu par langue et par canal, standards de classification pour le B2B (ETIM, GS1) et contrôles qualité avant toute publication.
• DAM : quand les équipes marque, marketing et produit partagent des milliers de ressources avec des droits d'utilisation.
• Recherche et merchandising : un moteur dédié avec des règles de merchandising par marché.
• Data warehouse : données d'analytics, d'ERP et de plateforme combinées en un seul endroit.
• Couche d'intégration : un middleware ou un iPaaS pour les flux qui relient plusieurs systèmes.

Beaucoup de boutiques de cette catégorie envisagent des front-ends headless ou composables. Lis ce qu'est le headless commerce et le composable commerce avant de t'engager : les deux augmentent le nombre de systèmes qui ont besoin de données produit propres, ils ne le réduisent pas.

Quoi acheter en premier : un ordre basé sur là où ça coince

Achète dans l'ordre du problème qui te coûte le plus d'argent aujourd'hui, pas dans l'ordre que suggère le schéma d'un éditeur. Un ordre pratique pour la plupart des boutiques en croissance :

Le PIM se trouve au milieu de cette liste pour une raison : la recherche, les feeds, l'e-mail et les avis lisent tous les données produit, donc les acheter avant que les données produit soient propres revient à configurer chacun deux fois.

Apps natives, middleware, API et fichiers planifiés : quatre façons de connecter les systèmes

La façon dont les systèmes communiquent compte autant que les systèmes que tu choisis. Il existe quatre modèles courants :

• Connecteurs et apps natifs : les plus rapides à mettre en place et les plus faciles à casser quand un côté change. Vérifie quels champs ils synchronisent et dans quel sens.
• Échange de fichiers planifié : des fichiers CSV ou XML selon un planning. À l'ancienne, facile à auditer, et suffisant pour les mises à jour de stock et de prix qui tournent toutes les heures ou chaque jour.
• API : un système appelle l'autre pour lire ou écrire des données. Le plus flexible ; il faut quelqu'un capable de maintenir l'intégration.
• Middleware ou iPaaS : une couche séparée qui déplace les données entre plusieurs systèmes et journalise chaque exécution. Rentable dès que tu as plus de trois ou quatre flux.

Pour chaque connexion, note le sens, les champs, le déclencheur (planning, changement ou manuel) et ce qui se passe quand une fiche échoue. Une configuration de commerce unifié, c'est surtout ce tableau rempli avec soin.

Sept choix de stack qui créent des fiches produit en double

1. Modifier les descriptions dans la boutique et dans le PIM. Le prochain envoi du PIM écrase la modification faite dans la boutique, ou la modification de la boutique n'atteint jamais la marketplace.
2. Des outils de feed qui réécrivent les titres. Les règles qui corrigent les titres dans le feed ne remontent pas, donc Google et ta boutique affichent des produits différents.
3. Deux systèmes qui revendiquent tous les deux le stock. Le connecteur marketplace et l'ERP écrivent tous les deux le stock dans la plateforme, et le dernier gagne.
4. Les noms de fichiers image comme seul lien vers un produit. Renomme un fichier et le produit perd son image.
5. De l'analytics sans données de commande. GA4 montre les sessions et les conversions mais pas la marge ni les retours, donc le meilleur vendeur en chiffre d'affaires peut être le pire en bénéfice.
6. Acheter la recherche ou les recommandations avant de corriger les attributs. Le moteur ne peut classer et filtrer que sur des champs qui existent.
7. Des apps qui injectent chacune leurs scripts. Dix apps qui ajoutent des scripts sur chaque page ralentissent la boutique ; vérifie le poids des pages quand tu ajoutes un outil.

Gérer PIM, feeds et analytics produit dans WISEPIM

WISEPIM couvre la partie PIM de la stack et une partie du travail de feed et d'analytics qui l'entoure. Il importe un catalogue, complète et corrige les données produit avec l'AI (descriptions, attributs, traductions et catégories), vérifie les fiches avec des règles Quality Guard et les pousse vers Shopify, WooCommerce, Magento 2, Lightspeed eCom, Ecwid, CCV Shop, Kaufland, PrestaShop, ShopWired et Google Merchant Center. Feed Hub génère les feeds de canaux, la médiathèque contient les images produit, et l'analytics combine les données de Google Analytics 4 et de Search Console avec les commandes importées depuis Shopify, WooCommerce, Magento 2, CCV Shop et Lightspeed.

Ce n'est pas un ERP, un système de gestion des commandes, un moteur de recherche de site, un outil d'e-mail ni une plateforme d'avis, et il n'a pas de connecteurs ERP. Pour les systèmes sans connecteur, l'API publique de l'offre Pro permet à tes propres intégrations de lire et d'écrire des produits, et des automatisations avec des déclencheurs planifiés exécutent les imports et exports récurrents.