Site web SaaS multiproduit : structure, pages produit et conversion.

Un site web SaaS qui présente plusieurs produits se conçoit à partir d'une question : comment vos produits sont-ils liés, et comment vos clients les achètent-ils ? Répondez-y d'abord, puis concevez une page d'accueil qui explique votre offre, des pages produit qui se suffisent à elles-mêmes et des parcours de conversion qui gardent le contexte du produit.

Parcourir des galeries de sites et des sites d'inspiration aide à trouver une direction visuelle, mais ne règle pas le problème central d'un éditeur SaaS multiproduit : aider l'acheteur à comprendre de quel produit il a besoin. Une page d'accueil soignée peut laisser le visiteur dans le doute : vendez-vous une plateforme unique, plusieurs outils indépendants ou une suite à acheter en bloc ? Ce guide propose un cadre pour organiser le portefeuille, construire des pages produit utiles et orienter chaque acheteur vers le bon essai ou le bon échange commercial.

01Partir d'un cadre de portefeuille, pas des maquettes

Un site web SaaS multiproduit présente plusieurs logiciels sous une marque commune. Son architecture de l'information découle de quatre décisions :

1. Cartographier les liens entre les produits.
2. Orienter chaque visiteur vers les options qui répondent à son besoin.
3. Démontrer la valeur de chaque produit sur sa propre page.
4. Gouverner le portefeuille de façon cohérente dans le CMS et le design system.

Partez de la réalité commerciale plutôt que de l'arborescence. Listez ce qui s'achète séparément, ce qui fonctionne ensemble et les produits qui s'adressent à des publics vraiment différents. Le site doit expliquer ces liens, pas masquer des choix d'offre qui ne sont pas encore tranchés.

Cartographier les liens entre produits avant de choisir une structure

La bonne architecture dépend de la façon dont vos clients évaluent et achètent vos produits. Prenons un éditeur fictif qui vend la paie, la planification des équipes et l'analyse RH. Certains acheteurs ne veulent que la paie. D'autres ont besoin de la suite complète. Les deux parcours méritent une explication claire, sans obliger le visiteur à comprendre l'organigramme interne de l'entreprise.

Des sites séparés ajoutent du travail de publication, de mesure et de maintenance. Choisissez-les pour une vraie raison d'audience ou d'organisation, pas parce que des équipes différentes portent des produits différents. Cela fait partie des décisions à prendre avant de créer un site B2B.

02Comment organiser la page d'accueil et la navigation d'un site web SaaS ?

Le premier rôle du site est d'aider le visiteur à reconnaître le bon chemin sans comparer toutes vos fonctionnalités.

Une page d'accueil qui explique votre modèle de produits

La page d'accueil dit ce que vend l'entreprise et comment les produits s'articulent. Si vous vendez une suite intégrée, expliquez l'usage commun avant de présenter ses briques. Si les produits répondent à des problèmes distincts, montrez ces différences dès le début. Évitez une promesse si large qu'elle pourrait décrire n'importe quel éditeur de logiciel.

Pour l'éditeur fictif, des cartes produit peuvent présenter la paie, la planification et le reporting RH comme trois métiers distincts. Chaque carte annonce le résultat et renvoie directement vers la page produit, au lieu de faire passer tout le monde par une nouvelle page générale.

Une page solution est utile quand le problème de l'acheteur touche vraiment plusieurs produits. Gérer des équipes réparties sur plusieurs sites, par exemple, peut mobiliser la planification et l'analyse. Cette page explique l'usage combiné, elle ne colle pas deux descriptions produit côte à côte.

Une navigation produit cohérente

La navigation doit rendre le portefeuille compréhensible depuis n'importe quelle porte d'entrée, y compris une page produit atteinte depuis un moteur de recherche. Concrètement :

• Associez au nom du produit une courte description fonctionnelle quand le nom seul est ambigu.
• Gardez une navigation globale stable et ajoutez une navigation locale pour le contenu détaillé de chaque produit. Les WCAG 2.2 l'exigent au niveau AA : une navigation répétée sur plusieurs pages doit apparaître dans le même ordre relatif (page en anglais).
• Choisissez les libellés selon la façon dont vos clients évaluent vos produits. Les noms de services internes, l'historique des rachats et les territoires commerciaux font rarement une bonne navigation.
• Permettez toujours de distinguer l'entreprise, la suite et le produit consulté.

Servez-vous des sites d'inspiration pour étudier les menus, puis testez le vôtre sur téléphone et au clavier avant de le valider. Le survol à la souris ne doit jamais être le seul moyen de découvrir un produit. Le tutoriel du W3C sur les menus déroulants (en anglais) explique comment garder les sous-menus utilisables au clavier et l'élément parent relié à une page de présentation.

03Que doit contenir chaque page produit ?

Une page produit doit fonctionner pour un visiteur qui n'a jamais vu la page d'accueil. Le tableau ci-dessous sert de cahier des charges minimal pour chaque page produit.

Gardez des preuves propres à chaque produit autant que possible. Un logo client prouve une relation avec l'entreprise, pas le produit utilisé. Présentez les témoignages, exemples de déploiement et cas clients avec exactitude, y compris quand un client utilise plusieurs produits ensemble.

Pour les ventes plus importantes, reliez la page aux informations de sécurité, d'intégration et de déploiement qui accompagnent les parcours d'achat B2B complexes. Des ressources de confiance communes peuvent servir tout le portefeuille, mais les limites propres à chaque produit doivent rester visibles. La vente croisée vient après la compréhension : expliquez d'abord le produit pour lequel le visiteur est venu, puis présentez un produit voisin quand il apporte une capacité utile.

04Un parcours de conversion adapté à chaque produit

L'étape suivante doit correspondre à ce que le visiteur évalue et à la façon dont le produit se vend. Un produit en libre-service mène à un essai, un produit qui demande un déploiement mène à un échange commercial. Gardez un système visuel cohérent, mais laissez l'action varier.

Conservez le contexte du produit quand quelqu'un envoie un formulaire. Un formulaire commun peut enregistrer le produit d'origine et laisser le visiteur indiquer plusieurs produits. L'équipe qui reçoit la demande doit disposer de ce contexte, pour que l'acheteur n'ait pas à tout réexpliquer.

Mesurez la conversion par produit autant que sur l'ensemble du site : visites des pages produit, essais démarrés, demandes de démo, opportunités acceptées par les commerciaux. Un taux de conversion global peut masquer un produit qui attire l'attention mais envoie des demandes mal qualifiées. Définissez les noms d'événements et les règles de routage avant le développement, et gardez les coordonnées personnelles hors des événements d'analytics : les règles de Google Analytics interdisent l'envoi de données permettant d'identifier une personne, comme une adresse e-mail.

05Gouverner le CMS et le design system comme un seul portefeuille

Un portefeuille qui grandit a besoin d'une structure commune, sans que toutes les pages se ressemblent.

• Modèle de contenu : traitez chaque produit comme une entrée réutilisable du CMS, avec des champs comme le nom, le public, le positionnement, les visuels et la destination de conversion. Reliez-y les intégrations, cas clients et ressources, au lieu de stocker ces liens dans des sections de page tenues à la main.
• Design system : partagez les composants de navigation, de typographie, de formulaires et les blocs de contenu courants (voir notre définition du design system). Laissez les pages produit varier quand le contenu l'exige, par exemple pour une démonstration d'usage.
• Couleur : une couleur par produit aide à se repérer, mais le critère WCAG 2.2 1.4.1 précise que la couleur ne doit pas être le seul moyen visuel de transmettre une information (page en anglais). Gardez des noms et des libellés explicites.
• Responsabilités : nommez un responsable du positionnement, des captures, des mentions de prix et des liens de chaque produit, avec une procédure pour les lancements, les changements de nom et les retraits.

C'est ce qui permet de créer un site professionnel évolutif sans accumuler d'affirmations contradictoires ni de pages obsolètes.

06Comment choisir une plateforme pour un portefeuille qui grandit

Choisissez la plateforme selon votre façon de publier, pas seulement selon l'allure de ses modèles. Avant de vous engager sur Webflow, Framer, un développement sur-mesure ou une autre solution, prototypez une page produit représentative avec ses liens de contenu. Demandez ensuite à l'équipe marketing de modifier une description, de remplacer une capture, de relier un cas client et de publier une nouvelle page. Cet exercice révèle des besoins qu'une maquette statique ne peut pas tester.

Séparez le site marketing de l'application logicielle dans le périmètre du projet. Une plateforme marketing n'a pas à héberger les comptes clients ni à reproduire les parcours connectés du produit. Une bonne évaluation des logiciels de développement de site web tient compte du coût d'exploitation et d'un futur changement de système, pas seulement du lancement.

07Éviter que les pages produit se concurrencent dans Google

Chaque page indexable doit avoir un objectif distinct et assez de contenu utile pour le porter. Attribuez une intention de recherche principale à chaque page produit, page suite et page solution. La page suite peut couvrir la plateforme connectée, les pages produit des usages plus précis. Évitez de publier plusieurs pages aux titres et aux textes presque identiques simplement parce que plusieurs équipes veulent se positionner sur le même terme.

Quand des produits se recoupent, expliquez directement la différence : un autre usage, un autre public ou un autre périmètre. Si vous n'arrivez pas à l'expliquer clairement, demandez-vous si des pages d'atterrissage séparées se justifient.

Les balises canoniques ne remplacent pas ce travail. Les recommandations de Google sur la canonicalisation (également disponibles en français) concernent les URL en double ou très proches (voir aussi notre définition de l'URL canonique). Des pages produit distinctes ont besoin d'une valeur propre, de métadonnées exactes et de liens internes que Google peut suivre : Google indique qu'il ne peut en général explorer que les liens en balise <a> avec un attribut href et recommande des textes d'ancre descriptifs. Quand un produit change de nom ou disparaît, revoyez son contenu et mettez en place une redirection permanente côté serveur plutôt que de laisser une page obsolète isolée du portefeuille.

08Les erreurs à éviter sur un site multiproduit

La plupart des problèmes viennent de liens flous entre produits ou d'une exécution incohérente, pas d'un manque de finition visuelle.

1. Présenter un catalogue comme une suite : regrouper des produits sous un même titre n'explique pas comment ils fonctionnent ensemble. Montrez l'usage commun, ou présentez-les comme des options séparées.
2. Cloner des pages sans changer l'argumentaire : un modèle commun est utile, mais chaque produit a besoin de son propre positionnement, de ses preuves et de ses réponses aux objections.
3. Envoyer toutes les demandes dans une file unique : conservez le produit concerné et fixez une règle de routage, y compris pour les acheteurs qui évaluent plusieurs produits.
4. Faire reposer l'identité d'un produit sur sa couleur : gardez noms, libellés et navigation explicites pour que la structure reste claire sans repère visuel.
5. Lancer un produit sans règle de responsabilité : décidez qui met à jour la navigation, les pages liées, la mesure et le routage commercial avant de publier un nouvel espace produit.

09La check-list avant le lancement

Relisez des parcours d'achat complets plutôt que de valider les pages une par une. Donnez aux relecteurs des tâches réalistes, comme trouver un produit vendu seul, comprendre une offre groupée ou demander une démo pour deux produits, puis demandez-leur ce qu'ils pensent pouvoir acheter. Leur interprétation est plus utile qu'un avis général sur la clarté du design.

Les tests d'accessibilité doivent s'appuyer sur un référentiel défini comme les WCAG 2.2, pas sur un simple contrôle visuel. Intégrez ces vérifications au périmètre des services de conception et de développement pour que chacun sache qui en est responsable avant le lancement.

10Fixer la structure des produits avant de lancer la refonte

Un site web SaaS multiproduit fonctionne quand le portefeuille est compréhensible et que chaque produit reste facile à évaluer. Votre premier livrable devrait être une carte des produits sur une page : publics, offres vendues seules, liens avec la suite, responsables des pages et destinations de conversion. Servez-vous-en pour trancher les désaccords de structure avant d'investir dans le design détaillé. Pour les contraintes propres aux éditeurs de logiciels, consultez notre page consacrée au SaaS.

11L'approche de BeBranded pour les sites SaaS multiproduits

Chez BeBranded, le conseil vient avant la production. Nous commençons par cartographier avec vous vos produits, vos publics et vos parcours de vente, puis nous traduisons cette carte en arborescence, en modèle de contenu et en bibliothèque de composants. Selon le projet, nous développons sur-mesure (Next.js et Payload) ou sur Webflow quand c'est le bon choix, et nous relions les formulaires à votre CRM et à vos automatisations pour ne pas perdre le contexte du produit. Nous concevons et faisons vivre nos propres produits (FlowConsent, Dashly et Nudge) : présenter plusieurs produits sous une même marque est une question que nous traitons aussi pour nous-mêmes. Pour transformer votre carte des produits en périmètre de projet, découvrez notre offre site web ou contactez-nous.