Le rendu serveur et la génération de métadonnées côté serveur appellent directement les modules de domaine ICM via la couche d'accès ICM ; le layout pré-charge l'arbre de catégories côté serveur et n'hydrate dans le navigateur que les interactions.
Le contrat est typé de la configuration ICM (IcmConfig) aux adaptateurs view-model, jusqu'au registre de feature flags ; les formulaires combinent la couche de formulaires et des schémas de validation Zod partagés.
La couche d'internationalisation émet toujours un préfixe de locale (en-US/fr-FR/de-DE) sur les routes localisées ; le sélecteur persiste le choix puis recharge, et la locale BCP-47 est convertie en forme ICM (en_US) à la frontière réseau.
Le middleware applique le routage d'internationalisation puis réconcilie le cookie de locale avec le segment d'URL, considéré comme source de vérité ; le cookie corrigé est réécrit dans les en-têtes de requête pour que le rendu serveur et le BFF servent ICM dans la bonne langue.
Le choix de devise est stocké dans un cookie et injecté par le transport serveur ICM sous forme de paramètres matriciels (;loc=;cur=) sur l'URL ICM, comme la Intershop PWA ; ICM renvoie alors les prix dans la devise demandée selon la configuration du canal.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Thème de marque centralisé
L'accent de marque est défini une seule fois - couleur, nom et métadonnées PWA - puis alimente le manifeste, les icônes installables, l'image Open Graph, le tint de la barre d'adresse et le token d'accent de l'interface.
Le registre de feature flags expose des gardes côté interface et côté BFF, afin qu'une fonction désactivée masque à la fois la page et sa route serveur ; deux variables d'environnement (allow-list et kill-list) règlent le périmètre sans fork.
La fabrique d'identité sélectionne le fournisseur à l'exécution selon la configuration, derrière une interface IdentityProvider commune (résolution de session, URL de login/logout/inscription) ; ICM-OAuth2 est le fournisseur par défaut, Auth0 reste un connecteur à finaliser.
Une stratégie PWA moderne, compatible avec le rendu serveur et les navigations applicatives.
FonctionnalitéAccélérateur IntershopReady
Manifest web et icônes installables
Le manifeste est généré côté serveur à partir du registre de marque, avec icônes 192/512 et maskable produites par la génération d'images à la volée à l'accent de marque, plus une icône Apple touch.
Le service worker maintient des caches versionnés : à chaque déploiement, les anciens caches sont évincés automatiquement pour éviter tout contenu périmé.
Une page hors-ligne trilingue (fr/en/de, langue détectée via le cookie de locale) est préchargée à l'installation du service worker et servie en dernier recours hors-ligne, logo et panier récent inclus.
La bannière hors-ligne signale la perte de réseau en s'appuyant sur les événements navigateur et une sonde HEAD réelle sur /manifest.webmanifest, car navigator.onLine peut mentir ; la détection est événementielle, sans polling périodique.
Le composant d'installation PWA enregistre le service worker, transforme beforeinstallprompt en bannière d'installation thématisée (avec repli « ajouter à l'écran d'accueil » sur iOS) et propose une bannière de mise à jour qui déclenche skipWaiting puis recharge.
Le service worker fait main isole cinq familles de caches versionnées : statiques, navigation, données catalogue et CMS sont segmentées par locale (préfixe d'URL), et les pages/API personnelles par le claim sub du JWT de session.
À la déconnexion, le storefront envoie un message PURGE_USER au service worker, qui supprime tous les caches utilisateur ; le balayage est volontairement large pour qu'aucune donnée personnelle ne reste lisible sur une machine partagée.
L'architecture est server-first : les pages sont produites par le rendu serveur et seuls les composants interactifs sont hydratés, ce qui limite le JavaScript embarqué à ce qui réagit réellement aux interactions de l'utilisateur.
Les images portent un attribut sizes responsive et sont chargées en lazy-load par défaut ; seules celles au-dessus de la ligne de flottaison reçoivent une priorité de chargement (eager + fetchpriority) pour protéger le LCP. L'optimisation de format (AVIF/WebP) dépend de la couche de livraison.
Le préchargement des routes vise une liste de routes publiques environ 1,5 s après l'affichage, en drainant une route par créneau d'inactivité et en respectant le mode économie de données, pour réchauffer le cache offline avec les charges serveur.
Le monitoring repose sur Sentry, chargé en import dynamique uniquement si la feature sentry est active, qu'une DSN est fournie par configuration et que l'analytique a été consentie ; capture d'erreurs et échantillonnage de transactions (10 %) restent désactivés par défaut.
Les fondations techniques nécessaires à l'indexation d'un catalogue multilingue.
FonctionnalitéAccélérateur IntershopReady
Métadonnées générées côté serveur
Deux fabriques (publicPageMetadata, privatePageMetadata) produisent titre, description, canonical et balises Open Graph lors de la génération de métadonnées côté serveur, alimentées par les traductions de la couche d'internationalisation selon la locale active.
Chaque page indexable expose un canonical pointant vers sa variante de locale courante (SITE_URL/{locale}{path}), aligné sur les URL du sitemap et des données structurées pour éviter les avertissements d'incohérence de Search Console.
alternatesFor() construit la table des langues alternatives avec une entrée par locale plus un x-default pointant vers la locale par défaut, exposée comme balises hreflang sur chaque surface publique.
Le point d'entrée /sitemap.xml émet un sitemapindex référençant quatre sous-sitemaps par type de contenu, ce qui permet à Search Console de rapporter la couverture par segment et de rester sous le plafond de 50 000 URL par fichier.
Sitemaps produits, catégories, CMS et pages statiques
Quatre points d'entrée distincts génèrent les sitemaps produits, catégories, pages CMS et routes statiques ; chaque URL est émise une fois par locale avec ses alternates hreflang, l'hôte étant dérivé de la requête entrante.
Un point d'entrée dédié rend robots.txt avec l'hôte dérivé de la requête, interdit les segments privés (compte, panier, checkout…) et ajoute une directive Content-Signal (ai-train, search, ai-input) pilotable par variables d'environnement.
Chaque page émet un bloc Open Graph complet (type, url, locale, alternateLocale) plus une carte Twitter summary_large_image ; l'image par défaut 1200×630 est produite côté serveur par la génération d'images à la volée, aux couleurs du thème B2C/B2B.
Les fiches produit rendent un JSON-LD @type Product côté serveur avec Offer (prix, devise, disponibilité, état), plus brand et mpn quand ICM les fournit et AggregateRating si des avis existent.
Données structurées Breadcrumb, Organization et Website
Le layout émet une fois Organization (nom, url, logo /apple-icon) et WebSite avec SearchAction éligible au sitelinks search box ; chaque PDP et catégorie ajoute un BreadcrumbList construit depuis le categoryPath ICM.
Trois schémas complémentaires : ItemList sur catégories et recherche, LocalBusiness par magasin (adresse, geo, contact) issu de l'endpoint ICM /stores, et FAQPage extrait prudemment des titres CMS terminés par « ? ».
L'accélérateur embarque des redirections prêtes à l'emploi : chemins hérités (ex. /store-finder → /stores) via la configuration, redirection 308 des fiches produit vers l'URL canonique avec slug, et redirections de locale ; les tables de correspondance propres à une migration se configurent par projet.
Derrière le feature flag merchant-feed (B2C, désactivé par défaut), un point d'entrée pagine le catalogue ICM et rend un flux RSS 2.0 namespace g:, un feed par locale via ?locale= ; identifiants, item_group_id et disponibilité suivent le vocabulaire Google.
Accélérateur IntershopReady Supporté OptionB2C
Surface agentique llms.txt et catalogue d'API
Sous le flag agentic (désactivé par défaut), le storefront publie /llms.txt et des miroirs Markdown /llms/{locale}/… des PDP, catégories et pages CMS, annoncés par en-têtes Link rel=alternate, plus /openapi.json et /.well-known/api-catalog décrivant la surface API publique.
Au-delà de llms.txt, le storefront expose un serveur MCP (Model Context Protocol) en lecture seule sur /api/mcp — des outils catalogue (recherche, navigation) en JSON-RPC, annoncé par /.well-known/mcp/server-card.json — et la découverte Agent Skills sur /.well-known/agent-skills (index + artefacts SKILL.md). Périmètre catalogue public, sans authentification.
Le middleware contrôle l'expiration du JWT de session et, s'il est périmé, déclenche un grant_type=refresh_token avant la route, puis réécrit les cookies de session et de rafraîchissement.
Un garde dans le middleware redirige vers /login (avec returnUrl) tout visiteur anonyme atteignant un segment protégé (account, orders, wishlists, organization-management…), en conservant le préfixe de locale.
Les formulaires partagent une bibliothèque de champs typés en Zod via la couche de formulaires, garantissant une validation et des messages d'erreur cohérents ; certains formulaires avancés restent à câbler sur ce socle.
La configuration émet X-Content-Type-Options, X-Frame-Options DENY, HSTS, Permissions-Policy et une Content-Security-Policy (report-only ou appliquée selon l'environnement), avec un en-tête dédié verrouillant le service worker.
La bannière de cookies propose accepter, refuser ou ouvrir /cookies, et persiste le choix par catégories (required, functional, analytics, marketing) dans localStorage sous cookieConsent, sans nouvelle sollicitation.
GTM ne s'injecte que si le feature flag tracking est actif, qu'un identifiant de conteneur est défini et que le visiteur a accepté la catégorie analytics ; un événement de consentement réévalue sans rechargement.
La page /data-request confirme une demande RGPD d'export ou de suppression via le lien e-mail (requestID + hash) ; le BFF appelle ICM en anonyme et distingue première confirmation, lien déjà utilisé ou invalide.
reCAPTCHA v3 est activable via le flag captcha et une clé de site fournie par configuration ; un jeton est émis par action juste avant l'envoi, et sans clé les formulaires fonctionnent sans challenge.
Une fabrique d'identité sélectionne le fournisseur selon la configuration : ICM OAuth2 par défaut, ou un connecteur Auth0 (vérification JWT contre le JWKS) déléguant SSO et MFA au fournisseur externe qu'il faudra intégrer.
Rendu des contenus ICM avec prévisualisation et invalidation ciblée du cache.
FonctionnalitéAccélérateur IntershopReady
Pages de contenu ICM
Les pages de contenu ICM sont chargées via /cms/pages, leur arbre pagelets/slots est aplati en une carte typée, puis chaque pagelet est rendu côté serveur selon son definitionQualifiedName, avec attributs SEO extraits des paramètres.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Navigation et menus issus du CMS
L'arborescence de catégories est préchargée côté serveur et alimente le mégamenu desktop et le tiroir mobile ; les pages d'aide et légales exposent une navigation latérale construite depuis /cms/pagetree.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Conteneurs et mises en page CMS
Le pagelet conteneur traduit le paramètre Grid d'ICM (paires point-de-rupture:colonnes, base 12 colonnes) en grille responsive pilotée par les tokens de design, et rend récursivement les enfants de chaque slot depuis la carte de pagelets partagée.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Texte riche et HTML libre sécurisé
Le HTML rédigé dans ICM passe par une réécriture des URI puis un assainisseur à liste blanche : balises et attributs autorisés uniquement, blocs script/style retirés, et href/src filtrés avant injection serveur.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Images, vidéos et carrousels
Les références de fichiers ICM sont résolues en URL statiques absolues ; les vidéos gèrent fichiers natifs et intégrations YouTube/Vimeo, et le carrousel découpe ses diapositives côté serveur avant de confier la lecture à un îlot client.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Listes produits manuelles, filtrées ou dynamiques
Listes manuelles (SKU saisies), par catégorie, par filtre ICM nommé, ou pilotées par endpoint REST ; ce dernier est borné à l'hôte ICM (garde anti-SSRF) et lit les SKU via l'enveloppe standard, sans exécuter de JS opérateur.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Dialogues et contenus réutilisables
Les includes réutilisables sont récupérés via /cms/includes et rendus là où ils sont déposés (accueil, pied de page) ; les pagelets de dialogue rendent leur slot de contenu, prêts à être déclenchés en modale.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Mode prévisualisation des contenus
Un paramètre ?PreviewContextID est capturé par le middleware dans un cookie, puis ajouté en segment matriciel ;pgid= aux appels ICM pour servir les brouillons sans cache ; le pont de prévisualisation dialogue par postMessage avec la Design View d'ICM.
Un endpoint protégé par jeton porteur reçoit l'événement de publication d'ICM et déclenche la revalidation à la demande des pages concernées (pageId, includeId, chemins explicites ou tout), déployée sur chaque locale.
Workflow, versioning et planification de publication
Le workflow de validation, le versioning et la planification restent gérés dans ICM ; le storefront en consomme le résultat en distinguant la surface publiée du brouillon (prévisualisation), puis se synchronise via le webhook de revalidation.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Catalogue, navigation & recherche
Les parcours de découverte du catalogue et les règles de merchandising exposées par ICM.
FonctionnalitéAccélérateur IntershopReady
Arborescence de catégories
Le module catégories parcourt l'arborescence ICM par niveaux (concurrence 8) et assemble un arbre typé de CategoryNode, consommé directement par le rendu serveur pour le méga-menu et reconstruit depuis un identifiant feuille si besoin.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Catégories et assortiments selon le contexte client
Chaque appel catégories transite par le transport serveur ICM avec la locale, la devise et le contexte canal/client, de sorte que la disponibilité en ligne et le nombre de produits par sous-catégorie reflètent l'assortiment résolu côté ICM pour le visiteur.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Pages catégories rendues côté serveur
La route /category/[...path] résout le chemin vers une catégorie ICM côté serveur, rend le fil d'Ariane à partir du categoryPath, redirige les liens à identifiant unique vers l'URL canonique et émet le JSON-LD breadcrumb/itemList.
La recherche interroge products?searchTerm côté serveur puis résout le détail de chaque SKU ; la page /search lit le ?q de l'URL comme source de vérité, de sorte qu'un rafraîchissement ou un partage reproduit les mêmes résultats, en noindex/follow.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Suggestions et autocomplétion
L'overlay de recherche interroge ICM /suggest (paramètre SearchTerm en PascalCase) via le cache de données côté client, et bascule sur les meilleurs produits correspondants quand l'index ne renvoie pas de termes ; navigation clavier au sein de la liste.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Facettes et filtres
Le composant de facettes rend côté serveur les groupes de /productfilters (marque, prix, couleur, fournisseur) en liens cliquables ; chaque clic fusionne le fragment de requête ICM dans le ?filter de l'URL, avec puces actives, basculement et grille de pastilles couleur.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Tri des listes produits
Le tri est transmis tel quel à ICM via le sortKey (name-asc, ProductSalePriceGross-desc, bestSellers, newest…) ; les options s'exposent en liens dans le tiroir tri-et-filtre et synchronisent le ?sort de l'URL, repris par le rendu serveur et le chargement progressif.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Pagination et chargement progressif
Le composant de chargement progressif associe un vrai lien crawlable (a href=?page=N) au rendu serveur de chaque page et une accumulation côté client : ajout via fetch, replaceState sur l'URL, auto-chargement par IntersectionObserver plafonné à trois pages, plus un « charger les précédents » pour les liens profonds.
Chaque parcours a son vide dédié : la recherche sans terme invite à parcourir le catalogue, une requête sans correspondance affiche un message clair, et une catégorie sans enfant ni produit rend une surface d'état vide avec retour au parent et accès au catalogue.
Un tracker monté sur chaque fiche produit pousse le SKU dans une liste MRU en localStorage (12 entrées max), restituée dans l'overlay de recherche et sur la page /recently, avec rafraîchissement sur focus, pageshow et événements storage entre onglets.
Un store côté client persiste en localStorage la liste des SKU à comparer ; la page /compare les résout via le cache de données côté client et rend un tableau à colonne d'étiquettes collante qui met en surbrillance les lignes d'attributs divergentes.
Règles de boost, synonymes et redirections de recherche
Le boost, les synonymes et les redirections par mot-clé sont appliqués par le moteur de recherche ICM côté serveur dans le contexte canal/client ; le storefront transmet simplement searchTerm et sortKey et restitue l'ordre et les correspondances renvoyés.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Produit & merchandising
Présentation des produits simples ou complexes et de leurs éléments de conversion.
FonctionnalitéAccélérateur IntershopReady
Produits simples, variantes et masters
Le produit est chargé côté serveur et adapté en modèle typé ; un master redirige (307) vers sa variante par défaut résolue depuis l'endpoint /variations d'ICM, et affiche un prix « à partir de » sur sa plage de variantes.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Attributs de variation
Chaque axe de variation ICM est restitué côté serveur : pastilles de couleur basées sur le code hex pour les axes couleur, pills de texte sinon, chaque valeur pointant vers la référence (SKU) de la variante correspondante.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Bundles, kits et retail sets
Bundles et kits affichés sur la fiche produit ; les retail sets exposent chaque membre avec son prix, une quantité ajustable, un total agrégé et l'ajout groupé au panier.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Galerie d'images responsive avec zoom
La galerie affiche un visuel unique ou une grille à deux colonnes selon le nombre d'images, avec ouverture en plein écran de la variante ZOOM d'ICM, navigation clavier, piège de focus et bande de miniatures.
Les pièces jointes liées au produit dans ICM (fiches techniques, notices, certificats) sont présentées en cartes téléchargeables, avec une icône déduite de l'extension du fichier ; la section disparaît si aucun document n'est rattaché.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Prix, promotions et prix barrés
Le prix ICM s'affiche avec prix de référence barré et pourcentage d'économie en cas de remise, plus une table de prix dégressifs par palier ; les promotions sont résolues via /promotions/{id} et respectent l'indicateur disableMessages.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Disponibilité et informations d'expédition
La disponibilité combine les indicateurs ICM inStock et availability pour piloter le buy-box, et le délai d'expédition s'affiche en « expédié sous X-Y jours ouvrés » à partir des bornes readyForShipmentMin/Max.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Unités de vente et quantités min/step
À côté du prix, une mention restitue les contraintes de conditionnement issues d'ICM : unité de vente, quantité minimale de commande et pas de commande ; elle n'apparaît que lorsque ces champs sont renseignés.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Avis, notes et dépôt d'avis
Derrière le feature flag « rating », les avis ICM sont chargés côté serveur avec note moyenne en étoiles, un formulaire poste un nouvel avis via le BFF, et la note agrégée alimente le JSON-LD du produit.
Accélérateur IntershopReady Supporté OptionB2C
Cross-sell et recommandations
Les recommandations sont résolues côté serveur depuis les liens ICM /products/<sku>/links (cross_selling, up_selling, accessories, replacement, similar), avec repli sur des produits de la même catégorie quand le catalogue n'en configure aucun.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Alertes de stock et de prix
Un utilisateur connecté s'abonne depuis la fiche produit : alerte de retour en stock sur un produit en rupture, et alerte de baisse de prix avec seuil sur un produit disponible, toutes deux notifiées par e-mail via ICM.
Derrière le feature flag « tacton » et une liste de SKU éligibles, la page /configure pilote l'assistant CPQ (démarrage de session, validation des valeurs, navigation entre étapes, soumission au panier) ; la reprise de configuration et la résolution de conflits restent à compléter.
Accélérateur IntershopReady Supporté OptionB2B
Panier, prix & checkout
Du mini-panier à la confirmation de commande, y compris les contraintes B2B.
FonctionnalitéAccélérateur IntershopReady
Mini-panier dans l'en-tête
Un popover dans l'en-tête qui s'ouvre 2,5 s à chaque ajout, avec compteur optimiste via un store côté client et aperçu des lignes alimenté par le cache de données côté client.
Les lignes sont gérées par identifiant de ligne ICM (et non par SKU) via le BFF panier : POST pour ajouter, PATCH pour la quantité, DELETE pour retirer, avec rafraîchissement du cache panier après chaque mutation.
Le panier est validé côté ICM par périmètre (stock, nombre de lignes, adresses) via POST /baskets/-/validations ; les messages transitoires de promotion et d'info ICM sont restitués dans une bannière dédiée (HTML assaini).
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Coupons et promotions
Les codes promo sont posés et retirés via les promotioncodes ICM ; la remise reste calculée dans les totaux du panier par ICM, et les codes invalides ou inactifs (HTTP 422) remontent en erreur de validation propre côté formulaire.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Commande rapide par SKU et quantité
Extension B2B activable par feature flag : une liste de lignes SKU + quantité ajoutée en lot, en parallèle, en isolant les échecs ligne par ligne, chaque échec étant signalé par SKU sans bloquer les ajouts réussis.
Accélérateur IntershopReady Supporté OptionB2B
Import CSV pour commande rapide
Import d'un CSV à deux colonnes (SKU, quantité), avec détection du séparateur virgule ou point-virgule et de l'éventuelle ligne d'en-tête, puis ajout au panier en mode tolérant : les lignes en échec sont listées sans annuler les autres.
Accélérateur IntershopReady Supporté OptionB2B
Adresses de facturation et livraison
Le checkout charge les adresses ICM, permet d'en sélectionner une distincte pour la facturation et d'en saisir une nouvelle directement dans le tunnel.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Checkout invité
Le checkout invité est implémenté : l'acheteur renseigne son e-mail et ses adresses de facturation/livraison (guest-address) et commande sans créer de compte.
Accélérateur IntershopReady Supporté Via ICMB2C
Modes de livraison et date souhaitée
Les modes éligibles sont chargés depuis ICM (eligible-shipping-methods) et appliqués via PATCH commonShippingMethod ; la date de livraison souhaitée est enregistrée comme attribut de panier ICM et bornée à aujourd'hui au minimum.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Click & Collect avec recherche de magasin
Localisateur de magasins activable par feature flag (B2C) : les points de vente ICM sont préchargés côté serveur par pays, complétés par la géolocalisation navigateur et un reverse-geocoding Nominatim pour préremplir et lancer la recherche automatiquement.
Accélérateur IntershopReady Supporté OptionB2C
Référence de commande client
Le numéro de commande externe de l'acheteur B2B est enregistré dans le champ externalOrderReference du panier ICM via PATCH (auto-save au blur), puis repris en lecture seule sur la page de récapitulatif du checkout.
Accélérateur IntershopReady Supporté Via ICMB2B
Centres de coûts et message au marchand
Sélecteur de centre de coûts limité aux centres éligibles de l'acheteur (PATCH costCenter) et message libre au marchand persisté comme attribut messageToMerchant du panier ICM ; tous deux masqués pour les clients B2C sans donnée.
Accélérateur IntershopReady Supporté Via ICMB2B
Paiements standards et paramètres PSP
Les moyens de paiement éligibles sont chargés depuis ICM ; les méthodes à paramètres (carte/IBAN) affichent un formulaire qui valide les contraintes ICM, crée l'instrument de paiement et l'attache au panier. Les PSP par redirection restent derrière un flag.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Paiements avec redirection
Les moyens de paiement à page hébergée (PayPal, PSP) sont identifiés via la capacité Redirect d'ICM mais restent désactivés derrière le feature flag payment-redirect (off par défaut) ; le retour gère les issues cancel et failure par notification.
Après commande, la page de confirmation affiche le numéro réel et purge le cache des commandes ; le suivi rend une frise à cinq étapes ancrée sur la date de création ICM, prête à recevoir les webhooks transporteurs (DPD, Colissimo, DHL).
Les fonctions self-service destinées aux acheteurs particuliers et professionnels.
FonctionnalitéAccélérateur IntershopReady
Création de compte et validation éventuelle
Le BFF crée un PrivateCustomer (ou un SMBCustomer professionnel) côté ICM avec validation captcha ; les particuliers sont connectés aussitôt, les comptes société sont routés vers l'écran d'approbation en attendant la validation administrateur.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Connexion, déconnexion et mot de passe oublié
La connexion échange les identifiants contre un jeton OAuth2 ICM stocké en cookie httpOnly et fusionne le panier anonyme ; la déconnexion purge les jetons et le mot de passe oublié passe par /security/reminder en répondant toujours 200 pour éviter l'énumération.
Le profil charge l'utilisateur courant et enregistre les modifications via un PATCH sur /users/me ; la page préférences résout langue, devise et granularité newsletter côté serveur pour livrer le formulaire avec les bonnes valeurs, sans flash client.
Le carnet d'adresses lit et écrit /customers/-/addresses (ou /privatecustomers pour les particuliers) via le BFF sécurisé, avec un schéma de validation piloté par pays et rafraîchissement du cache à chaque création ou suppression.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Instruments de paiement enregistrés
Les instruments enregistrés sont restitués depuis /users/me/payments via la session BFF, avec affichage des références masquées et suppression à la demande ; l'ajout d'un nouveau moyen reste dans le tunnel de paiement.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Historique et détail des commandes
La liste des commandes provient d'ICM via la session BFF, et chaque détail est rendu côté serveur à partir de fetchRealOrder puis adapté en modèle typé : lignes, adresses, transporteur, paiement et récapitulatif des coûts.
Accélérateur IntershopReady Supporté Via ICMB2C + B2B
Réassort depuis une commande passée
Un bouton rejoue toutes les lignes d'une commande passée vers le panier courant en parallèle, en isolant chaque échec individuel (rupture, produit retiré) pour signaler les articles indisponibles sans bloquer les autres.
Le détail de commande déclenche l'impression native du navigateur, avec une mise en page épurée pour le papier : les actions et badges marqués print:hidden disparaissent au profit du seul contenu de la commande.
Derrière un feature flag B2C, les clients connectés gèrent plusieurs listes via le BFF : création, renommage, suppression, liste préférée, plus déplacement et retrait d'articles entre listes ; les visiteurs anonymes conservent une liste unique en localStorage.
Accélérateur IntershopReady Supporté OptionB2C
Modèles de commande
Les modèles B2B se consultent et se gèrent dans le compte ; toutes leurs lignes s'ajoutent au panier en une fois, avec un rapport des éventuels articles indisponibles.
Accélérateur IntershopReady Supporté OptionB2B
Tableau de bord contextuel
Le tableau de bord agrège commandes, panier, adresses et wishlist en tuiles de synthèse avec un flux des commandes récentes et des accès rapides ; une section organisation n'apparaît que pour les utilisateurs B2B, selon leurs autorités ICM et les feature flags actifs.
Module optionnel désactivé par défaut : la case d'abonnement n'apparaît dans le profil que si le paramètre de canal marketing.newsletterSubscriptionEnabled est actif dans /configurations, doublée d'un bloc d'inscription chargé en différé dans le pied de page.
Les parcours d’achat professionnels, d’administration et d’approbation disponibles dans le storefront.
FonctionnalitéAccélérateur IntershopReady
Gestion des utilisateurs de l'organisation
Le compte organisation liste, crée et modifie les utilisateurs B2B du client via la route BFF customers/-/users ; l'accès est conditionné à la permission ICM de gestion des utilisateurs portée par la session.
Accélérateur IntershopReady Supporté OptionB2B
Rôles et permissions B2B
Les rôles ICM sont restitués dans le compte organisation et chaque action (création, édition, suppression, budgets) n'est exposée qu'aux utilisateurs disposant de la permission correspondante.
Accélérateur IntershopReady Supporté OptionB2B
Import CSV des utilisateurs
Un import CSV crée des utilisateurs en masse : chaque ligne porte profil, colonnes de rôles APP_B2B et budget, puis est traitée séquentiellement (création, affectation des rôles, budgets) avec suivi ligne par ligne.
Accélérateur IntershopReady Supporté OptionB2B
Budgets récurrents et plafonds par commande
Pour chaque acheteur, un budget récurrent sur une période (hebdomadaire à annuelle) et un plafond par commande sont définis via PUT users/{login}/budgets ; ICM calcule côté serveur le dépensé et le restant.
Accélérateur IntershopReady Supporté OptionB2B
Centres de coûts et affectation des acheteurs
Les centres de coûts sont créés avec un propriétaire et un budget, puis des acheteurs y sont rattachés avec leur propre budget et période via customers/-/costcenters/{id}/buyers.
Accélérateur IntershopReady Supporté OptionB2B
Import CSV des centres de coûts
Un import CSV crée les centres de coûts en masse (identifiant, libellé, propriétaire, budget et période), chaque ligne donnant lieu à un POST séquentiel avec un statut affiché ligne par ligne.
Accélérateur IntershopReady Supporté OptionB2B
Demandes d'achat
L'acheteur consulte ses demandes d'achat et le détail de chaque ligne ; la liste est lue sur users/me/requisitions avec le login réel de la session.
Accélérateur IntershopReady Supporté OptionB2B
Approbation ou rejet avec commentaire
L'approbateur traite une demande via PATCH avec un statut APPROVED ou REJECTED ; un rejet exige un commentaire non vide, validé dans la fenêtre avant l'envoi à ICM.
Accélérateur IntershopReady Supporté OptionB2B
Déclenchement selon budgets et règles ICM
Quand les règles B2B et budgets ICM imposent une validation, le panier remonte approvalRequired ; le checkout remplace « Passer commande » par « Soumettre pour approbation », et ICM crée la demande à la soumission.
Accélérateur IntershopReady Supporté Via ICMB2B
Création de devis depuis un produit ou le panier
Deux entrées créent une demande de devis : « Ajouter au devis » depuis une fiche produit, qui alimente le brouillon actif, et la conversion du panier entier, réservée aux utilisateurs B2B connectés.
Accélérateur IntershopReady Supporté OptionB2B
Édition et soumission d'une demande de devis
Tant qu'une demande de devis n'est pas soumise, l'acheteur ajuste les quantités, supprime des lignes et modifie nom et description, regroupés en un seul envoi ; la soumission crée le devis côté ICM.
Accélérateur IntershopReady Supporté OptionB2B
Réponse commerciale, acceptation ou refus
Le devis renvoyé par le commercial est en lecture seule, avec ancien prix barré et fenêtre de validité ; son état (répondu, expiré, rejeté) est calculé côté client et l'acheteur peut le rejeter.
Accélérateur IntershopReady Supporté OptionB2B
Transformation du devis en panier
Un devis ayant reçu une réponse est ajouté au panier via POST baskets/{id}/quotes ; les lignes issues du devis sont ensuite regroupées dans le panier avec leur en-tête et une action de retrait dédiée.
Accélérateur IntershopReady Supporté OptionB2B
Catalogue et prix spécifiques au client
Les requêtes catalogue et produit étant signées par le jeton de session B2B, ICM applique le catalogue et les prix contractuels du client ; les prix par paliers sont récupérés via productprices et affichés dans le buy-box.
Accélérateur IntershopReady Supporté Via ICMB2B
Punchout & e-procurement
Une couverture dédiée aux achats intégrés SAP, Ariba, Coupa et autres systèmes procurement.
FonctionnalitéAccélérateur IntershopReady
Entrée punchout OCI 5
Le point d'entrée /punchout détecte les paramètres OCI (HOOK_URL, USERNAME, PASSWORD), authentifie l'acheteur par OAuth password grant, puis route selon FUNCTION : détail produit, validation prix ou recherche silencieuse.
Accélérateur IntershopReady Supporté OptionB2B
Entrée punchout cXML 1.2
Sur réception des paramètres cXML (sid, access-token), le jeton pré-émis par le système procurement est installé dans la session via une route dédiée, puis les métadonnées de session (ReturnURL, basketId) sont chargées avant redirection vers le catalogue.
Accélérateur IntershopReady Supporté OptionB2B
Transfert du panier vers le système procurement
Un bouton de transfert n'apparaît sur le panier que si un contexte punchout est présent ; il sélectionne le protocole actif et renvoie le panier au système procurement, sans impact sur le checkout standard.
Accélérateur IntershopReady Supporté OptionB2B
Gestion des utilisateurs OCI et cXML
L’espace d’administration permet de créer et maintenir les utilisateurs punchout ainsi que leurs paramètres OCI ou cXML.
Accélérateur IntershopReady Supporté OptionB2B
Configuration des mappings OCI
Au niveau client, chaque règle OCI (champ, transform, formatter) est éditable avec un sous-éditeur de correspondances « valeur ICM → valeur procurement », puis l'ensemble est enregistré en un seul aller-retour vers ICM.
Accélérateur IntershopReady Supporté OptionB2B
Configuration cXML par utilisateur
Comme les adaptateurs Ariba ou Coupa divergent par locataire, la configuration cXML est portée par utilisateur : chaque entrée (nom, valeur, valeur par défaut, type de saisie) est éditée puis renvoyée à ICM via PATCH.
Accélérateur IntershopReady Supporté OptionB2B
Session cXML et jeton d'accès
Le jeton d'accès pré-émis est posé en cookie httpOnly via une route protégée par contrôle d'origine same-origin, conditionnant la lecture des métadonnées de session ICM ; faute de refresh token, la durée de vie suit l'expires_in du jeton procurement.
Accélérateur IntershopReady Supporté OptionB2B
Retour sécurisé vers le HOOK_URL / ReturnURL
Le renvoi vers le système procurement valide d'abord l'URL cible (HTTPS ou même origine), puis poste un formulaire auto-soumis : tableau d'attributs OCI vers le HOOK_URL, ou message PunchOutOrderMessage XML dans un champ cXML-urlencoded vers la ReturnURL.
Accélérateur IntershopReady Supporté OptionB2B
Intégrations & exploitation
Les points d'extension nécessaires à une exploitation industrielle.
FonctionnalitéAccélérateur IntershopReady
API REST ICM consommée côté serveur
Un transport serveur unique appelle l'API REST ICM (/INTERSHOP/rest/WFS), gère la locale et la devise par paramètres matriciels et l'en-tête Accept par ressource, sans exposer ICM au navigateur.
Chaque domaine ICM (panier, produits, commandes, devis, demandes d'achat) possède son module serveur qui appelle le transport et normalise la réponse JSON en un modèle typé avant rendu.
Les erreurs ICM sont converties en un type unique porteur du statut, du code et du corps structuré ; le wrapper BFF répercute les codes métier 4xx et masque les pannes d'infrastructure derrière un 502 propre.
Les formulaires combinent la couche de formulaires et Zod ; une bibliothèque de champs centralise schéma de validation et métadonnées d'affichage, partagés entre le rendu et le contrôle des saisies.
Une couche de tracking pousse les événements e-commerce dans un dataLayer compatible GTM, GA4 ou Tealium ; elle ne s'active que si le flag est activé, l'identifiant de conteneur configuré et le consentement analytique accordé.
Le SDK Sentry n'est chargé en import dynamique que si le flag, le consentement analytique et une DSN sont réunis ; sans DSN ou sans accord, la capture d'erreurs reste inerte et hors du bundle.
Le serveur en mode production répond directement au sondage des plateformes d'hébergement ; les variables d'environnement sont validées par des schémas de validation au premier appel, faisant échouer tôt un déploiement mal configuré.
Le build standard (compilation puis démarrage) se déploie sur les plateformes cloud ou un hébergement autonome ; toute la configuration ICM, identité et CDN passe par des variables d'environnement, sans dépendance à une plateforme.
Un scaffolding REST, désactivé par défaut, expose les sessions de checkout agentique sous /api/ucp avec schémas de validation Zod, idempotence et vérification JWT ; une couche ICM sans cookie crée de vrais paniers et commandes, avec repli gracieux.
Des garde-fous techniques pour maintenir la qualité dans la durée.
FonctionnalitéAccélérateur IntershopReady
HTML sémantique et navigation clavier
Les listes produits sont des ul[role=list], la recherche expose un combobox ARIA piloté au clavier (flèches, aria-activedescendant, Échap) et les radios de checkout sont reliées à leur titre via aria-labelledby.
Un lien d'évitement, premier élément focusable de chaque page, cible #main-content puis y déplace le focus par programmation (WCAG 2.4.1) ; un indicateur :focus-visible global trace le parcours clavier.
Libellés, erreurs et états de formulaires accessibles
Les champs partagent un composant unique liant label, aria-required, aria-invalid et aria-describedby vers le message d'erreur ; la couche de formulaires et Zod valident, les boutons portent aria-busy en soumission.
Une règle globale prefers-reduced-motion neutralise animations, transitions et transitions de vue ; côté script, les navigations animées vérifient aussi matchMedia avant de déclencher un effet.
Des specs ciblées vérifient la logique critique sans navigateur réel : dispatch des fonctions OCI punchout, validation d'adresses, suggestions de recherche et régressions de l'audit d'accessibilité.
Les capacités B2C et B2B, le SEO, la performance, la PWA, le CMS, le checkout, le punchout et l'architecture. La page Fonctionnalités présente une matrice consultable et filtrable du niveau de prise en charge.
Toutes les fonctionnalités sont-elles disponibles dans chaque stack ?
Oui : Next.js, Nuxt et Angular SSR partagent le même périmètre fonctionnel. Seule la technologie front diffère, pas les capacités métier.
Le B2B avancé (organisations, punchout, Tacton) est-il géré ?
Oui : organisations, rôles, budgets, devis et réquisitions, punchout OCI/cXML et configurateur CPQ Tacton sont pris en charge pour les scénarios B2B.