Site Web SaaS : le Design d'une Plateforme de Netlinking

Ce projet est la création d'un site web SaaS pour Pressmerit, une plateforme de PR digitale et de partenariats dédiée au netlinking. Le logiciel lit votre site, cherche sur le web ouvert les éditeurs à qui il vaut la peine d'écrire, note chaque candidat, trouve un contact vérifié et rédige le pitch. L'envoi se fait depuis votre propre boîte mail. Une fois le lien en ligne, la plateforme le vérifie puis le recontrôle tous les 30 jours.

Nous avons pris en charge le site marketing de bout en bout : positionnement, architecture de l'information, système visuel, fragments d'interface présents sur toutes les pages, textes et couche de SEO technique. Treize pages, une langue, développées avec Next.js et déployées sur Vercel.

Le brief posait une contrainte ferme. Le netlinking est une catégorie où les acheteurs se sont déjà brûlés, le site ne pouvait donc pas vendre comme on vend habituellement ici. Chaque affirmation devait arriver avec sa preuve, et chaque tarif devait figurer sur la page avant toute inscription. La version générale de cet argument est dans notre guide sur le site web de startup.

Trois problèmes se présentaient en même temps.

Le produit est un pipeline, pas une fonctionnalité. Analyser, découvrir, rédiger, envoyer, vérifier. L'expliquer comme une liste de fonctionnalités aurait fait manquer l'essentiel : la plateforme fait le travail de fond et s'arrête aux deux décisions qui reviennent à un humain.

Il n'y avait aucune capture d'écran disponible. Le produit était en pré-lancement, et les vraies données clients n'ont de toute façon pas leur place sur une page marketing. Des maquettes de dashboard génériques auraient eu l'air de ce qu'elles sont.

Et le site s'adressait à deux publics qui ne se croisent jamais. Des acheteurs SEO évaluant un abonnement à 49 $, et des éditeurs qui ont reçu un e-mail de prospection et veulent savoir qui leur écrit avant de répondre. Ne servir que le premier aurait abîmé la réputation du produit auprès du second, un dégât qui n'apparaît que des mois plus tard dans les taux de réponse.

Consultez nos offres tarifaires pour voir comment nous cadrons ce type de projet.

Le pipeline a dicté la structure. La page d'accueil parcourt les cinq étapes qui mènent du domaine au lien vérifié en ligne et signale les deux où l'utilisateur agit. Une page longue développe ce même pipeline en huit étapes avec une ancre chacune, y compris ce que la plateforme ne sait pas faire. Tout le reste du site se rattache à une étape, la navigation est donc une carte du produit et non une liste de services.

À la place des captures, nous avons reconstruit l'interface sous forme de fragments de code : une carte d'analyse avec les composantes de son domain score, une liste de prospects notée, un contact vérifié avec son indice de confiance, un pitch rédigé, une frise de monitoring. Chacun utilise des données d'exemple de sites fictifs et le précise en légende. Ce sont du texte et du CSS : ils restent nets à toute résolution, ne coûtent presque rien au chargement et se modifient quand le produit évolue.

Les tarifs sont publiés en entier. L'offre, la table complète des crédits par action, un exemple de mois chiffré et un simulateur qui applique la même arithmétique que le tableau au-dessus. Rien n'est gardé pour un appel commercial, puisqu'il n'y en a pas.

Le côté éditeur a reçu ses propres pages. Une page explique ce qu'est une demande de collaboration et ce que font ses trois boutons, une autre répond à la question de savoir pourquoi on a reçu l'e-mail, une troisième documente le crawler de vérification avec son user agent et son calendrier. Elles existent pour être liées depuis l'e-mail de prospection lui-même, là où la question de la confiance se pose vraiment.

Le système visuel est éditorial plutôt que SaaS générique : une serif pour les titres, une monospace pour les libellés, les données et les éléments d'interface, et un seul accent chaud. Les fragments d'interface se lisent comme de l'interface, le texte comme du texte, et les deux ne se disputent jamais l'attention. Cette séparation travaille plus qu'il n'y paraît, car elle garde une page longue lisible sans une seule illustration décorative.

Quatre pages du site en ligne, chacune traitant une partie différente du problème de design.

Le site a été lancé avec 100 en Performance, Accessibilité, Bonnes pratiques et SEO sur Lighthouse desktop. Largest Contentful Paint à 0,5s, aucun décalage de mise en page, aucun temps de blocage. Sur mobile, la Performance s'établit à 96 et les trois autres catégories restent à 100.

Ces chiffres découlent de la décision qui a façonné le design. Construire les fragments d'interface en balisage plutôt qu'en images fait que les éléments visuels les plus lourds de la page coûtent quelques kilo-octets de HTML. Il n'y avait donc aucun budget images à optimiser plus tard. La plupart du travail de performance sur un site marketing est en réalité une décision de design prise en amont, comme le rappellent les Core Web Vitals de Google.

Chaque page est rendue côté serveur, porte les données structurées Organization, WebSite, SoftwareApplication et FAQPage, et figure dans un index llms.txt avec un résumé d'une ligne. Les blocs FAQ ont été écrits comme des questions que les gens tapent réellement, ce qui les rend exploitables autant par les moteurs de recherche IA que par Google.

Les pages éditeurs ont produit un effet que nous n'attendions pas à ce point. Elles transforment l'e-mail de prospection en document à double sens. Celui qui reçoit une demande peut lire qui la formule, ce qu'est la plateforme et comment se désinscrire, sans compte et sans répondre au préalable.

Audits Lighthouse au lancement, desktop et mobile.

Six décisions de ce projet se transposent à la plupart des projets de site web SaaS, quel que soit le produit.

Laissez le produit fixer l'ordre des pages. Si le logiciel exécute une séquence, le site doit suivre la même séquence. Une grille de fonctionnalités demande au visiteur de reconstituer l'histoire lui-même, et la plupart ne s'en donneront pas la peine.

Mettez l'interface sur la page en balisage. Les fragments d'UI reconstruits battent à la fois les maquettes génériques et les vraies captures. Ils chargent plus vite, survivent à une refonte du produit, et les données d'exemple peuvent être signalées honnêtement au lieu de suggérer une clientèle inexistante.

Publiez les tarifs. Pour tout ce qui est en libre-service, la page tarifs est l'appel commercial. Affichez les coûts unitaires et laissez le visiteur faire le calcul avant de s'inscrire.

Écrivez les limites. Dire ce que le produit ne fait pas est le signal de confiance le moins cher qui existe, et il écarte les prospects qui auraient résilié en troisième semaine.

Donnez des pages au second public. La plupart des produits SaaS B2B touchent quelqu'un d'autre que l'acheteur : un validateur, un partenaire, un destinataire. Ces personnes sont à une recherche de votre site, et une page écrite pour elles protège la réputation du produit.

Traitez la performance comme une décision de design. Choisir le balisage plutôt que des fichiers image a produit le score Lighthouse de 100, pas une passe d'optimisation finale. Notre approche de la phase de design est détaillée sous design UX/UI, et la structure des sites plus larges sous sites corporate.