Les informations produit deviennent complexes plus vite qu'il n'y paraît.

À mesure qu'un catalogue s'agrandit, ses données se dispersent entre feuilles de calcul, boutiques, dossiers et différentes équipes. Modifier un seul produit peut alors demander de répéter la même opération à plusieurs endroits, tandis que préserver la cohérence de l'ensemble devient progressivement plus difficile.

J'ai voulu explorer ce que pourrait être une plateforme de données produit si cette complexité restait dans le système au lieu d'atteindre l'utilisateur.

C'est ainsi qu'est né CycleCore : un SaaS B2B conçu pour centraliser, structurer, enrichir et distribuer les informations produit depuis un seul endroit.

J'ai pris en charge le produit de bout en bout : compréhension du problème, conception, développement, tests et déploiement de la plateforme.

• Découverte produit et échanges avec les utilisateurs
• Stratégie produit et définition des fonctionnalités
• Parcours utilisateurs et architecture de l'information
• Product design et design d'interaction
• Design system
• Développement full-stack
• Conception des API et du modèle de données
• Intégrations avec des services tiers
• Tests et qualité
• Infrastructure cloud et déploiement
• Démonstrations produit et retours de bêta
• Documentation et onboarding

Le plus intéressant n'a jamais été de simplement dessiner une interface ou développer une fonctionnalité. Il fallait décider ce que le produit devait faire, comment le système devait se comporter en arrière-plan et comment conserver la clarté de l'ensemble à mesure que la plateforme grandissait.

Je n'ai pas commencé par des écrans.

La première étape a consisté à comprendre comment les marques géraient déjà leurs informations produit : où vivaient leurs données, comment elles circulaient entre les outils, où apparaissaient les tâches manuelles et ce qui devenait pénible lorsque les catalogues grandissaient.

J'ai échangé avec des personnes issues d'une dizaine d'entreprises et utilisé ces conversations pour remettre en question l'idée initiale.

Certaines hypothèses ont résisté. D'autres non.

L'un des changements les plus importants concernait l'architecture. CycleCore reposait initialement sur des utilisateurs individuels. Lorsque la collaboration est devenue centrale, j'ai repensé le modèle autour des organisations, permettant à un utilisateur d'appartenir à plusieurs espaces avec leurs propres rôles, permissions, produits et intégrations.

Cette décision a changé bien plus que la base de données. Elle a touché l'onboarding, la navigation, l'authentification, les permissions, la facturation et presque tous les parcours du produit.

À partir de là, mon processus suivait généralement la même boucle :

Comprendre → structurer → prototyper → développer → tester → présenter → affiner.

La plupart des fonctionnalités commençaient dans Figma, mais j'ai évité de trop séparer design et implémentation. Travailler sur les deux permettait aux contraintes techniques d'influencer la conception très tôt, tandis que les problèmes d'usage découverts en développement pouvaient encore modifier le système sous-jacent.

Les démonstrations externes et la bêta ont ensuite rejoint cette boucle. Les retours ont entraîné des changements de layout, des parcours plus simples et de nouvelles priorités autour des intégrations et des échanges de données.

Le produit a évolué au fil de ces itérations plutôt qu'en suivant une spécification figée.

À mesure que l'interface grandissait, concevoir chaque écran indépendamment n'avait plus de sens.

J'ai créé un design system réutilisable réparti dans trois bibliothèques Figma :

Fondations :
Typographie, espacements, couleurs, tokens et langage visuel fondamental du produit.

Base UI Kit :
Composants réutilisables tels que les champs, boutons, tableaux, éléments de navigation, statuts et contrôles.

Layouts & Patterns :
Structures de plus haut niveau pour les parcours récurrents et les écrans complexes.

L'objectif n'était pas de construire un design system pour le simple fait d'en avoir un.

CycleCore contient des interfaces denses : tableaux de produits, attributs, filtres, imports, intégrations, permissions, médias et écrans de configuration. La cohérence réduisait la quantité d'informations nouvelles que les utilisateurs devaient assimiler à chaque déplacement dans le produit.

Comme j'implémentais également les interfaces, le système devait fonctionner visuellement autant que techniquement. Les composants devaient rester réutilisables dans Figma et se traduire naturellement en React.

Le catalogue produit se trouve au cœur de CycleCore.

Produits, variantes, attributs, catégories et médias peuvent tous être structurés depuis un même espace, plutôt que maintenus indépendamment sur différents canaux.

Mais centraliser les données ne résolvait qu'une partie du problème.

Importer les données

Commencer avec un PIM vide n'est pas particulièrement utile.

J'ai conçu l'onboarding pour importer rapidement un catalogue existant dans la plateforme, soit depuis des feuilles de calcul, soit grâce à des intégrations e-commerce.

Pour les fichiers CSV et Excel, les utilisateurs peuvent associer leurs colonnes existantes à la structure de données de CycleCore avant l'import. Le système valide les valeurs et les relations, transforme les données et présente des erreurs structurées lorsqu'un élément ne peut pas être importé.

L'essentiel était que le système s'adapte aux données existantes de l'utilisateur, plutôt que d'exiger de lui une restructuration préalable.

Conserver des données exploitables

Une fois les produits dans la plateforme, les indicateurs de complétude et la validation permettent d'identifier les informations manquantes avant leur distribution.

La recherche, les filtres, les actions groupées, la gestion des médias et l'historique des changements ont été pensés pour des catalogues où gérer chaque produit individuellement deviendrait rapidement inefficace.

Plus la plateforme traitait de données, plus je me suis intéressé au design d'opérations complètes plutôt qu'à celui d'actions isolées.

Connecter le catalogue

Une des principales questions produit est alors devenue :

Si CycleCore est la source de vérité, comment doit-il communiquer avec tout ce qui l'entoure ?

Cette réflexion a mené à une intégration Shopify bidirectionnelle.

Produits, variantes, images, catégories, collections et données basées sur les attributs peuvent circuler entre les deux systèmes par synchronisation manuelle ou planifiée.

J'ai conçu la couche d'intégration avec des adaptateurs et des factories afin que l'application ne soit pas étroitement couplée à Shopify. La même architecture pourra ensuite prendre en charge des plateformes aux structures de données entièrement différentes.

C'est l'un des moments où la réflexion produit et l'architecture logicielle sont devenues presque impossibles à séparer.

Gérer les permissions sans perdre en simplicité

La collaboration a introduit un autre défi.

Chaque organisation contrôle les accès différemment. J'ai donc construit des permissions configurables basées sur les rôles, plutôt que de coder en dur un petit ensemble de rôles prédéfinis.

Les administrateurs peuvent créer des rôles, y associer des permissions et attribuer plusieurs rôles au même utilisateur.

Derrière l'interface, chaque requête protégée valide également l'organisation active, l'adhésion, les rôles et les permissions nécessaires.

L'interface reste relativement simple parce que l'essentiel de la complexité vit sous sa surface.

Parler aux utilisateurs avant de protéger ses hypothèses.

Certains des changements les plus importants de CycleCore sont nés de conversations plutôt que de l'implémentation.

La découverte m'a orienté vers de meilleures capacités d'intégration, un autre modèle d'organisation et des parcours produit plus simples.

Construire davantage n'était pas toujours la réponse. Il fallait parfois modifier la structure sous ce qui existait déjà.

Les décisions produit deviennent étonnamment vite des décisions d'architecture.

Une question apparemment simple comme « Un utilisateur peut-il travailler avec plusieurs organisations ? » finit par toucher l'authentification, les relations de la base de données, les permissions, la navigation, la facturation et les API.

Prendre en charge le produit de bout en bout m'a appris à anticiper ces conséquences beaucoup plus tôt.

La complexité n'a pas besoin de disparaître. Elle doit se déplacer.

Les données produit sont intrinsèquement complexes.

L'objectif n'a jamais été de prétendre le contraire, mais de déplacer autant que possible cette complexité dans le système afin que l'interface reste compréhensible.

Ce principe a fini par influencer à la fois le design et l'ingénierie.

Frontend

TypeScriptReactNext.jsTailwind CSSShadCNTanStackMotion

Backend

Node.jsNestJSAPI RESTZodSwagger / OpenAPI

Intégrations

ShopifyStripeSupabaseAPI OpenAIWebhooks

Tests

JestTests unitairesTests d'intégrationPostman

Infrastructure

AWSEC2RDSS3CloudFrontCloudWatchDocker

Déploiement

GitGitHubGitHub ActionsIntégration continue

Données

PostgreSQLPrisma

Produit & Design

FigmaNotion