Le diagnostic de site Web SaaS que votre agence peut réutiliser sans que les clients se ressemblent

Résumé

Combien de fois ce trimestre avez-vous mené exactement le même appel de découverte—mêmes questions sur le produit, le client, le concurrent—pour deux clients qui insistaient sur le fait qu'ils étaient complètement différents ? Vous savez déjà que les réponses seront différentes, mais les missions que chaque site SaaS doit accomplir, elles, ne changent pas. Chaque site Web de produit SaaS est un petit ensemble de machines qui exécutent les mêmes tâches : expliquer ce que fait le produit, montrer son coût, dire aux développeurs comment l'intégrer, répondre aux objections qui bloquent l'achat, et prouver que l'entreprise est crédible. Un diagnostic reproductible qui audite ces cinq missions survivra au contact de n'importe quel client, car les missions ne changent pas. Le système que vous construisez autour est ce qui vous permet de passer d'une mission à l'autre sans repartir de zéro. Cela prend moins de temps que votre processus de découverte actuel, donne au client une raison claire de vous faire confiance, et produit un livrable qui ne semble pas sorti d'un modèle, car les questions sont standard mais les réponses sont spécifiques.

Combien de fois ce trimestre avez-vous mené exactement le même appel de découverte—mêmes questions sur le produit, le client, le concurrent—pour deux clients qui insistaient sur le fait qu'ils étaient complètement différents ? Vous savez déjà que les réponses seront différentes, mais les missions que chaque site SaaS doit accomplir, elles, ne changent pas. Chaque site Web de produit SaaS est un petit ensemble de machines qui exécutent les mêmes tâches : expliquer ce que fait le produit, montrer son coût, dire aux développeurs comment l'intégrer, répondre aux objections qui bloquent l'achat, et prouver que l'entreprise est crédible. Un diagnostic reproductible qui audite ces cinq missions survivra au contact de n'importe quel client, car les missions ne changent pas. Le système que vous construisez autour est ce qui vous permet de passer d'une mission à l'autre sans repartir de zéro. Cela prend moins de temps que votre processus de découverte actuel, donne au client une raison claire de vous faire confiance, et produit un livrable qui ne semble pas sorti d'un modèle, car les questions sont standard mais les réponses sont spécifiques.

« Mes clients sont trop différents pour un seul système »

Appliquez le même diagnostic en cinq points à chaque client avant d'écrire un mot de contenu ou d'ouvrir un outil de conception. Les différences qui rendent vos clients spéciaux—secteur, audience, modèle tarifaire—reposent sur une base commune. Un SaaS de paie et un outil de planification des réseaux sociaux n'ont rien en commun sauf les cinq missions que chaque page accomplit. Si vous auditez ces missions, vous trouverez les mêmes schémas aux mêmes endroits.

Page ou section	Ce que votre client demande habituellement	Ce qui se passe réellement sur la page
Vitrine des fonctionnalités	« Montrer toutes les fonctionnalités que nous avons construites »	Montrer le résultat obtenu par l'utilisateur, pas seulement la fonction. Les visuels comme les captures d'écran, les GIF ou les vidéos doivent démontrer un moment où le produit change la façon de travailler.
Tarifs	« Rendre les prix faciles à lire »	L'acheteur est obligé de décider quel plan lui convient. Les paliers doivent être lus comme une progression qui guide un choix, et non comme une simple liste de prix.
Documentation API	« Nos développeurs trouveront cela dans la documentation »	C'est souvent le premier test qu'un développeur effectue pour évaluer si le produit est digne de confiance. La clarté ici est une fonctionnalité, pas un supplément.
Section FAQ	« Répondre aux questions pour réduire les appels au support »	C'est la dernière chose qu'un acheteur lit avant de cliquer sur un bouton. Elle doit traiter les objections sur le prix et les cas particuliers, pas seulement les questions génériques sur l'entreprise.
Preuve sociale	« Mettre les logos en avant »	La preuve que les affirmations faites précédemment sont vraies. Les logos et les témoignages sont des indicateurs de confiance, pas une décoration.

Un diagnostic n'est pas un modèle. C'est un ensemble de questions que vous posez à chaque page : cela permet-il à l'acheteur de comprendre ce que fait le produit, cela rend-il l'étape suivante évidente, cela répond-il à l'objection qui bloque actuellement la vente ? Lorsque vous posez ces questions en présence du client, celui-ci vous voit comme la personne qui comprend son marché, plutôt que comme la dixième agence qui a présenté un diaporama. La recherche sur les sites Web SaaS cite des entreprises comme HubSpot, Slack et Zendesk comme exemples de sections FAQ bien organisées, et Stripe, GitHub et Twilio comme références en matière de clarté de documentation. Aucune de ces entreprises n'y est arrivée en traitant la FAQ comme une pile de tickets de support. Ils l'ont traitée comme une surface de conversion. C'est l'attitude que votre diagnostic doit apporter à chaque client.

Prenons un client qui vend un logiciel d'inventaire et un autre qui vend un logiciel de paie. Le diagnostic révèle souvent les mêmes trois lacunes : la page des fonctionnalités mentionne des modules au lieu de résultats, la page de tarification ne justifie pas le saut entre les plans, et la FAQ répond à des questions de support plutôt qu'à des hésitations d'achat. Comme vous avez constaté ces lacunes dans les deux cas, vous savez exactement quoi demander à l'étape de la conception. Le client voit un processus spécifique, pas générique. Rédigez le diagnostic sous forme de PDF d'une page avec un score de 1 à 5 pour chaque mission, et une note pour chacune. Partagez-le avec le client avant le lancement de la conception. Cela vous donne un vocabulaire commun et transforme l'audit en un livrable que vous pouvez facturer. C'est le cœur d'un système reproductible, et nous avons un guide séparé sur la façon de mettre ce système en place ici.

« Cela rendra notre travail semblable à celui de tout le monde »

Standardisez les questions que vous posez, pas les réponses que vous livrez. Le diagnostic vous donne une grille d'évaluation, pas une mise en page. La recherche sur les vitrines de fonctionnalités SaaS montre qu'elles utilisent des visuels comme des captures d'écran, des GIF ou des vidéos, mais le contenu de ces visuels est différent pour chaque produit. La fonctionnalité de rapport de salaire dans un outil RH et la fonctionnalité de lecture de codes-barres dans un logiciel d'inventaire ne se ressembleront jamais. Ce qui reste constant, c'est la question que vous posez à votre esprit stratégique : « Cette page montre-t-elle le résultat, ou seulement la fonction ? »

Le formulaire d'admission d'un médecin ne rend pas tous les diagnostics identiques ; il rend le médecin fiable. Votre cadre est le formulaire d'admission. Le client reçoit toujours un site Web personnalisé, mais vous obtenez un diagnostic reproductible. Ce qui rendra réellement votre travail générique, c'est l'absence de diagnostic—car sans lui, vous revenez à la même image hero, à la même mise en page de fonctionnalités en trois colonnes, à la même structure de page d'accueil que vous avez utilisée pour le dernier projet, juste pour aller vite. Le diagnostic vous oblige à justifier la structure à partir des preuves, de sorte que chaque site est structurellement différent là où il doit l'être.

En pratique, cela signifie que le diagnostic peut vous suggérer de commencer la page des fonctionnalités d'un client par une vidéo d'un assistant d'importation et celle d'un autre par un GIF d'un générateur de rapports par glisser-déposer. La structure de la page reste la même, mais les éléments visuels, le texte et le rythme sont uniques. Le client voit un travail sur mesure ; vous voyez un processus reproductible. Lorsque vous présentez le diagnostic à un client, vous démontrez que vous savez ce que chaque site SaaS doit faire. C'est un argument plus fort que « nous allons créer un design unique ». Le design est la conséquence du diagnostic, pas le point de départ.

« Nous n'avons pas le temps d'auditer chaque page »

Faites la version ciblée de 90 minutes, pas un audit complet. La plupart des processus de découverte des agences sont déjà un audit, mais non structuré. Vous passez quarante-cinq minutes sur un appel de découverte qui couvre le contexte, les concurrents et « ce que vous attendez de cela », puis vous passez des semaines à réagir. Le diagnostic inverse cela : vous évaluez les cinq missions, listez les correctifs à plus fort impact, et passez à la conception. Cela fait gagner du temps car vous cessez de refaire le travail après la première revue de conception. Les correctifs les moins chers sont ceux que vous faites avant que quiconque ne voie des pixels.

Voici une répartition concrète de 90 minutes : le bloc un (30 minutes) passe en revue la page d'accueil et la page des fonctionnalités pour les cinq missions. Le bloc deux (30 minutes) survole la page de tarification et la FAQ. Le bloc trois (15 minutes) vérifie si la documentation API répond à « puis-je extraire les données », et les 15 dernières minutes listent les correctifs prioritaires et leur responsable pour chacun. Vous n'avez pas besoin de lire chaque page de haut en bas ; vous devez déterminer si la mission est accomplie. Si la page de tarification n'a pas de FAQ, la conception sera approuvée plus rapidement si vous le remarquez avant de créer une maquette de la quatrième colonne de tarification. Si la documentation API est rédigée selon une norme interne plutôt que selon la norme du développeur, vous le savez avant de donner les instructions au rédacteur.

Lors d'une mission, le diagnostic a révélé que l'acheteur cible était terrifié par la migration des données. La FAQ que nous avons ajoutée pour répondre à cette question a coûté deux heures de rédaction. Sans le diagnostic, cette crainte nous aurait suivis tout au long de la conception, du développement, et jusqu'à une surcharge de support après le lancement. La version de 90 minutes n'est pas une phase qui précède le projet ; c'est la première phase du projet. Elle vous donne aussi une façon honnête d'estimer : vous quittez la session avec une liste de ce qui existe et de ce qui n'existe pas, de sorte que la proposition que vous rédigez repose sur des preuves plutôt que sur des suppositions.

« Mon client non technique n'a pas besoin de documentation API »

Utilisez un arbre de décision, pas une liste de contrôle : si le produit a une API publique ou une histoire d'intégration, la documentation API est une page essentielle ; sinon, sautez-la consciemment. La recherche sur la documentation API est directe : des entreprises comme Stripe, GitHub et Twilio fixent la norme en matière de clarté de documentation parce que leurs développeurs sont en réalité les acheteurs. Si votre client a une intégration destinée aux développeurs, la documentation n'est pas une commodité pour développeurs ; c'est un dispositif de confiance qui se place à côté de la page de tarification. Un client non technique ne la regardera peut-être jamais, mais le développeur qui évalue un achat, lui, la regardera absolument.

L'arbre de décision fait partie du système. Quand le client dit « nous n'avons pas d'audience de développeurs », posez une question : « une partie de votre processus d'intégration nécessite-t-elle qu'un développeur connecte le produit à un autre système ? » Si oui, la documentation reste. Si non, vous l'ignorez et mettez l'effort dans la FAQ et la preuve sociale. Appliquez la même logique à la preuve sociale : pour un client, une rangée de logos suffit ; pour un autre, un témoignage détaillé avec des résultats mesurables est nécessaire. Le diagnostic vous dit lequel, plutôt que de recourir par défaut à tous les logos que vous pouvez collecter. Ce choix est ce qui rend le cadre reproductible sans être rigide. Si vous avez besoin de comprendre ce que « clarté » signifie en pratique, ce guide sur la documentation API explique la structure.

« Mais mon client veut une liste de fonctionnalités, pas des résultats »

Quand le client dit qu'il veut montrer ses fonctionnalités, demandez-lui de nommer la tâche utilisateur que chaque fonctionnalité débloque. L'hypothèse courante est que la vitrine des fonctionnalités est l'endroit où l'on gagne la vente. Le diagnostic suggère le contraire : sur un site SaaS typique, la page de tarification est l'endroit où se fait le calcul mental final, et la FAQ est l'endroit où la dernière objection est résolue. La vitrine des fonctionnalités est essentielle, mais sa mission est étroite—montrer le moment où le produit devient précieux. Une longue liste de fonctionnalités avec un paragraphe sous chacune ne fait pas cela.

Les clients résistent parce qu'une liste semble tangible et facile à approuver. Mais une page de cinquante fonctionnalités produit un visiteur qui survole, et un visiteur qui survole votre page de fonctionnalités a déjà déplacé son attention vers le tableau des tarifs. La mission de votre système est de mettre le client à l'aise avec le compromis : vous ne supprimez pas de fonctionnalités, vous les déplacez là où elles seront lues. Une FAQ bien placée qui dit « nous nous intégrons aux outils que vous utilisez déjà » fait souvent plus de travail qu'une page de fonctionnalités qui dit la même chose sous le mauvais titre. C'est la nuance que la plupart des articles ignorent, et c'est exactement le type de compromis qu'un diagnostic peut rendre explicite.

Le diagnostic vous donne aussi une raison défendable de résister à l'expansion du périmètre. Quand un client demande d'ajouter une autre rangée de fonctionnalités à la page d'accueil, vous pouvez pointer le tableau et dire « la mission de cette page est de montrer des résultats, pas de cataloguer des fonctionnalités ». Un générateur de pages générique pourrait créer une grille de fonctionnalités, mais il ne peut pas décider si la grille doit être remplacée par une vidéo ou une FAQ. Cette décision est le véritable produit, et c'est la raison pour laquelle un cadre ne commodifie pas votre travail.

« Nous avons déjà un processus interne »

Si votre agence a un processus pour la page d'accueil ou une liste de contrôle pour la page de tarification, l'objection porte généralement sur le fait de ne pas vouloir le remplacer. Vous n'avez pas à le faire. Le diagnostic en cinq missions ne remplace pas votre processus créatif ; c'est une interface qui l'alimente. Le problème avec la plupart des processus internes, c'est qu'ils sont invisibles. Ils vivent dans la tête du designer senior. Le diagnostic rend le processus externe, de sorte qu'un membre junior de l'équipe peut effectuer le premier passage, et vous pouvez le revoir en quelques minutes. C'est la reproductibilité dont vous avez réellement besoin dans une agence avec plusieurs clients.

Un processus visible change aussi la conversation avec les clients. Au lieu de « nous avons un processus de conception propriétaire », vous pouvez dire « nous effectuons un diagnostic sur les cinq missions que chaque site SaaS doit accomplir, puis nous concevons en fonction des résultats ». La première phrase est une boîte noire qui rend les clients nerveux. La seconde est une méthode claire qui les invite à participer. Le diagnostic devient une partie de votre argumentaire commercial, pas seulement un outil de production.

« Le client dit que le site actuel est bien »

Le diagnostic fonctionne même si le client ne veut qu'un rafraîchissement. Il vous donne une référence. Vous évaluez le site actuel et montrez qu'une page spécifique échoue dans une mission spécifique. Vous pouvez dire : « Votre page FAQ est organisée, mais elle ne répond pas à la question que votre équipe commerciale entend chaque semaine »—et c'est une raison factuelle de changer, pas une préférence esthétique. C'est souvent la façon la plus douce de commencer une refonte : vous ne dites pas au client que son site est laid, vous lui dites qu'une mission n'est pas accomplie.

Cela vous protège aussi de l'échec courant où un client insiste pour conserver un élément de la page d'accueil qu'il adore mais qui nuit à la conversion. Le diagnostic vous donne le vocabulaire pour dire « cet élément n'accomplit aucune des cinq missions », et le client peut voir la preuve. L'objection n'est plus une question de goût.

Le diagnostic est le produit

La reproductibilité ne consiste pas à faire entrer chaque client dans le même modèle. Il s'agit de mettre en œuvre un processus standard qui fait ressortir ce qui est unique chez chaque client. Le diagnostic en cinq missions prend moins de deux heures, donne à votre équipe un langage commun et au client une liste claire de décisions. L'agence qui peut promettre un diagnostic cohérent peut décrocher un client en une semaine et livrer en un mois, non pas parce que le travail est plus facile, mais parce que la découverte est prévisible. Et quand le client demande pourquoi vous devez poser autant de questions, la réponse est simple : vous ne passez pas une audition, vous établissez un diagnostic.

Pour un regard plus approfondi sur la façon dont la vitrine des fonctionnalités et la page de tarification devraient fonctionner ensemble, et pourquoi les mythes qui les entourent persistent, consultez ce guide qui démystifie.