Nomad X Collective

À la mi-2025 encore, nomadxcollective.com fonctionnait sur un logiciel de boutique standard. Il est conçu pour un marchand : un entrepôt, un compte d'expédition, une personne qui met à jour les prix. Le commerce derrière était depuis longtemps tout autre. Nomad X Collective sélectionne des marques indépendantes qui vendent aussi leur provenance, chacune avec son propre entrepôt, son propre compte d'expédition et sa propre idée de ce qu'il faut dire d'un vêtement. Si l'on force ces marques dans un système qui ne connaît qu'un seul marchand, quelqu'un finit par tout ressaisir, et chaque modification devient un e-mail.

La mission était donc la suivante : trois systèmes reliés qui donnent l'impression d'une seule marque et qui servent trois groupes d'utilisateurs aux tâches très différentes.

• Exploitation de la plateforme : commandes, chiffre d'affaires et nouvelles inscriptions en un coup d'oeil, sans que personne n'ait à construire un tableur.
• Marques partenaires : leur propre catalogue, leur propre page de marque, leurs propres étapes de traitement, sans développeur à disposition.
• Clientes et clients : un achat qui donne l'impression d'une sélection et non d'un gabarit de place de marché.

S'y ajoutait le calendrier. La plateforme devait être lancée en même temps qu'un rebranding complet, l'interface côté client devait donc porter une nouvelle identité visuelle pendant que, en dessous, une place de marché fonctionnait pour la première fois.

Nous avons construit la plateforme comme trois systèmes reliés au-dessus d'une base de données commune et nous avons réparti l'effort de conception de façon inégale. La boutique porte l'intégralité du rebranding, les panneaux admin et vendeur fonctionnent sur une interface de base plus sobre et fonctionnelle. C'est un ordre de priorité, pas une économie : les processus en dessous doivent d'abord être justes, car un beau panneau vendeur avec un mauvais statut de commande ne vaut rien.

1. Données partagées, autorité séparée

• Les produits, les variantes, les stocks, les commandes et les données clients se trouvent dans une base de données que les trois systèmes interrogent via la même interface REST.
• L'autorité sur les contenus reste séparée. Les identifiants des marques sont créés de façon centralisée, afin que l'onboarding reste à un seul endroit ; les données de marque et de produits d'une marque lui appartiennent ensuite.
• Toutes les images se trouvent dans un bucket S3 en eu-central-1. Les logos de marque et les images des pages de marque sont stockés séparément par marchand, les images de produits se trouvent dans un espace de noms commun, parce qu'elles sont liées au produit et non à la marque.

2. L'import est le véritable travail de traduction

Les marques arrivent souvent avec une boutique existante, sur Shopify ou WordPress par exemple. Le panneau vendeur propose pour cela un bouton qui connecte la boutique externe. L'import évite la ressaisie, mais il ne résout pas à lui seul le problème le plus difficile. Deux boutiques décrivent le même vêtement différemment : les tailles portent des noms différents, les noms de couleurs sont des appellations maison, et ce qu'une boutique gère comme deux produits est chez l'autre une variante du même produit. Sur une place de marché avec des filtres communs, il faut en faire un vocabulaire, sinon le filtre par couleur se disperse en synonymes et ne trouve rien. La portée d'un rapprochement dépend en outre de ce que la plateforme externe concernée expose via son API. Nous l'avons dit ainsi au client, plutôt que de promettre une synchronisation complète.

3. Le contenu éditorial comme jeu de données

La page d'accueil, la page à propos, le contact, le pied de page, le programme partenaires et les ateliers sont chacun une configuration que la boutique charge à l'exécution ; les pages de marque forment un jeu de données structuré à part. Les images, les textes et la visibilité de sections entières peuvent ainsi être modifiés sans que personne ne déploie.

Chaque marque partenaire expédie depuis son propre site via son propre compte d'expédition. Il n'existe donc pas de flux d'envois commun que la plateforme pourrait lire, ni de moyen d'interroger le statut de livraison côté serveur.

Cela concerne plus que l'affichage du statut. Lorsque l'expédition relève de la marque, une commande portant sur deux marques donne forcément lieu à deux expéditions : deux colis, deux délais, deux liens de suivi. Le panier indique donc les frais de port par marchand et ne les additionne qu'ensuite. Pour la même raison, nous avons modélisé le retour et le remboursement comme un flux de travail à part. Un remboursement touche à la fois le stock, le versement au marchand et la communication client, et il porte en règle générale sur une partie de la commande, pas sur la totalité.

Le déroulement est donc construit autour de la relation d'expédition réelle :

1. La marque met sa partie de la commande sur « expédié » et y enregistre le lien de suivi généré par son propre compte.
2. C'est exactement ce lien qui part automatiquement par e-mail.
3. « Livré » est confirmé manuellement par la marque dès qu'elle le voit de son côté.

Un statut de livraison automatique ne serait ici qu'une supposition, et une promesse supposée vaut moins qu'une information honnête. La boutique dit donc exactement ce que le système sait, et là où la question se pose. Dans la section expédition de la page produit, on lit « Each shipment is managed directly by our brand partners; therefore, costs and delivery times vary based on your location. », et plus bas dans la même section « Once your order has been dispatched, you will receive a tracking link via email. »

La boutique est la surface sur laquelle l'histoire de la marque devient un achat. La page d'accueil a une structure fixe faite d'un hero vidéo, de « Latest Arrivals » et de « Meet Our Brands », dont les contenus sont définis par la rédaction. Structure fixe, contenus libres : une mise en page sans dérive, une rédaction sans déploiement.

1. Catalogue

• Filtres par catégorie, marque et couleur, tri par nouveauté et par prix, navigation par pages avec 16 articles par page.
• Les tailles et les variantes de couleur figurent déjà dans la vignette, tout comme la liste d'envies et le panier. Qui sait déjà quelle taille et quelle couleur il lui faut n'a pas besoin d'ouvrir la page produit.
• Le panier et la liste d'envies fonctionnent sans compte grâce à un identifiant invité côté serveur. La connexion se fait par mot de passe, code à usage unique ou Google.

2. Page produit

La page produit est en couches. Sous l'image, la taille et le prix se trouvent des sections dépliables, et c'est la marque qui décide lesquelles par ses propres contenus. Un pantalon mongol en yak porte sa propre section de transparence avec le lieu de production ; une maille fabriquée en Italie réunit composition, provenance et entretien dans une seule section et y indique sa certification. En dessous figure la marque avec son nom, son histoire et un lien vers sa propre page.

3. Pages de marque

Chaque marque partenaire reçoit sa propre page avec la même structure : l'histoire de la marque, les blocs Material Traceability, Production Process, Origins & Resources et Maintenance & Repair ainsi que ses propres produits en bas de page. La provenance devient ainsi une structure dans le système, que chaque marque remplit elle-même. Les marques partenaires la remplissent avec des contenus très différents, d'un fabricant mongol fondé en 1991 à une collection de maille fabriquée en Italie.

Le panneau vendeur donne à chaque marque partenaire son propre espace de travail avec cinq domaines : tableau de bord, page de marque, gestion des produits, gestion des commandes et paramètres. Une marque doit pouvoir modifier une description ou marquer une commande comme expédiée sans mobiliser quelqu'un de l'équipe plateforme.

1. Le produit est une enveloppe, la variante est la marchandise

Un produit porte un titre, une description et une variante de base ; ce qui est vendu est toujours une variante avec son propre SKU, ses propres attributs de taille et de couleur et son propre prix. C'est pourquoi une marque peut vendre une couleur plus cher qu'une autre et laisser certaines variantes passer en « rupture de stock » pendant que le produit reste actif.

Le stock n'y figure pas comme un seul nombre, mais comme trois : la quantité, la part réservée, et la disponibilité qui en découle. Cette séparation fait la différence entre une place de marché qui vend deux fois la même dernière pièce et une qui ne le fait pas.

2. Deux décisions marquent la conception

• L'onboarding est un état, pas un formulaire. La progression est enregistrée à chaque étape, une marque peut donc interrompre la configuration et la reprendre plus tard. Le prix à payer, c'est que des marques à moitié configurées ont le droit d'exister : elles doivent figurer dans le système sans apparaître dans le catalogue.
• L'étape d'expédition exige une saisie. Le lien de suivi est la seule information du cycle de commande dont la plateforme ne dispose pas elle-même, et donc le seul point où le panneau exige quelque chose avant de poursuivre.

Pour de petits fabricants qui travaillent de façon très réfléchie, cela détermine si la croissance est possible sans gérer en plus une entreprise de logistique.

Une place de marché ne reste curatée que si quelqu'un relit. En même temps, cette relecture ne doit pas signifier qu'une marque écrive un e-mail pour chaque légende d'image. Nous avons séparé les deux : la marque écrit elle-même, mais ne publie pas elle-même.

La page de marque est pour cela créée dans le panneau comme une configuration de six sections, chacune modifiable séparément : hero, description, grille d'informations, galerie, entretien et identité de marque. Le hero accepte au choix une image ou une vidéo, et le texte alternatif figure à côté comme un champ à part et non comme une arrière-pensée, car sinon il ne verrait jamais le jour.

À la fin, il n'y a pas de « Enregistrer », mais Submit For Approval. Deux versions coexistent donc : celle sur laquelle la marque travaille actuellement, et la dernière validée, que la boutique diffuse. Le panneau indique les deux au même endroit, à savoir que la page est en ligne et de quelle version il s'agit. Les produits passent par le même mécanisme, c'est pourquoi la liste des produits affiche toujours un statut de validation à côté du titre et des variantes.

L'effet, c'est qu'une faute de frappe sur une page de marque ne coûte rien et qu'une présentation non concertée ne passe malgré tout pas en ligne. Le prix, c'est une file d'attente que quelqu'un doit traiter, et c'est précisément pour cela que la validation se limite à la page de marque et au catalogue de produits et ne s'étend pas à chaque changement de stock.

Les deux panneaux sont construits autour des mêmes indicateurs : commandes, chiffre d'affaires, commandes récentes et commandes ouvertes. Nous avons commencé par le tableau de bord, parce que la question des commandes et du chiffre d'affaires coûtait auparavant un export et un tableau croisé dynamique.

En dessous se trouve l'objet véritable, le cycle de commande. Il connaît six états, et leur répartition est le premier graphique qu'une marque voit après sa connexion :

• Pending, Packed, Shipped, Delivered comme parcours normal. « Packed » se place volontairement entre la réception et l'expédition, parce que pour une marchandise faite main plusieurs jours peuvent séparer les deux et qu'une cliente n'apprendrait sinon pas qu'il se passe quelque chose.
• Cancelled et Refunded comme les deux sorties. Ce ne sont pas des cas d'erreur, mais des états finaux avec leurs propres conséquences pour le stock et le versement.

À côté figurent les tâches qui n'appartiennent qu'à la plateforme : la gestion des utilisateurs et des marchands avec blocage et déblocage, l'historique des commandes et l'export CSV pour la comptabilité, le cycle complet y compris les retours et les remboursements ainsi que la remise des identifiants aux nouvelles marques partenaires.

Les e-mails transactionnels passent par Brevo, afin que la confirmation d'expédition, le retour et la création de compte empruntent le même canal de distribution et restent traçables en cas de doute. Sur une place de marché dont les envois viennent de plusieurs directions, l'e-mail est le seul canal que la plateforme contrôle entièrement.