Audit SaaS — Revenue Centric Design (RCD)
Auditez n'importe quel SaaS pour que sa conception serve la valeur utilisateur ET les revenus en même temps. Cette compétence transforme un corpus de connaissances en conception comportementale en un audit répétable qui révèle des points d'amélioration concrets et priorisés — chacun lié à un biais cognitif ou principe nommé, avec une correction recommandée.
Source et crédit. Ces frameworks synthétisent des publications et articles publics de Richard — "Design for startups" (@richardrx) : Revenue Centric Design, le Swiss Knife Index, les 4 phases de startup, la tarification GBB, le filtre de fonctionnalités, et plus encore. La science sous-jacente est attribuée à ses créateurs (Kahneman & Tversky, Dan Ariely, Eugene Schwartz, Aronson & Mills, Nir Eyal, Fitts, Hick, Nielsen Norman Group). Appliquez la persuasion de manière éthique — voir Porte éthique.
Thèse centrale
La conception neutre n'est pas "objective" — c'est une omission. Une interface qui ne guide pas délibérément l'attention rend le chemin vers la valeur plus long et les revenus plus difficiles. Une bonne conception produit n'est jamais valeur utilisateur ou revenu d'entreprise ; elle est les deux, par construction. Les biais cognitifs sont les leviers ; le cycle de vie client est la carte ; la phase de startup fixe les priorités.
Ce que fait cette compétence
Étant donné un SaaS (une URL, des captures d'écran, une description, un code source, ou une surface spécifique comme "notre page de tarification"), produisez un audit : une liste priorisée de points d'amélioration, chacun avec des preuves, le biais/principe violé, une correction concrète, et une estimation effort×impact. Fonctionne pour un audit complet ou ciblé (juste la tarification, juste l'onboarding…). Pour une demande ciblée, réalisez d'abord les étapes 0–1 (phase + ICP) — elles recadrent tout — puis passez à l'étape pertinente.
Workflow d'audit
Copiez cette checklist dans vos notes de travail et remplissez-la :
Progrès de l'audit :
- [ ] Étape 0 : Phase de startup calibrée (ARR/MRR + priorités)
- [ ] Étape 1 : Clarté de l'ICP vérifiée
- [ ] Étape 2 : Cycle de vie parcouru (Acquisition → Activation → Rétention → Monétisation → Métriques)
- [ ] Étape 3 : 9 principes RCD notés
- [ ] Étape 4 : Checklist maître exécutée
- [ ] Étape 5 : Résultats émis dans le modèle de rapport
Étape 0 — Calibrer à la phase de startup → references/startup-phases.md
L'échec le plus courant est d'appliquer les conseils de la mauvaise phase (boucles de croissance de phase d'échelle à un produit en phase de survie). Établissez l'ARR/MRR (ou une meilleure estimation) et définissez ce qui compte :
| Phase | Plage ARR | Objectif | Où la conception paie |
|---|---|---|---|
| Survie | 0–240k | Prouver que quelqu'un paie | Différenciation visuelle, couche de confiance, rapidité vers la valeur |
| Traction | 240k–1.2M | Chance ou système ? | Comportemental : onboarding, TTV, réalisation de valeur, leviers d'upsell, contrôle du churn |
| PMF | 1.2M–6M | Prouver l'échelle (les utilisateurs arrivent, restent, recommandent) | Efficacité de rétention, marge |
| Échelle | 6M+ | Concurrencer pour l'attention | Optimisation continue + défendabilité (effets de réseau, fossé de données) |
Étape 1 — Vérifier la clarté de l'ICP → references/acquisition.md
Tout en aval dépend d'un ICP précis et mal desservi qui : (a) ressent la douleur avec un poids réel (la perte en cas de non-résolution est grande), (b) est assez grand (TAM bottom-up), (c) peut payer le ticket dont votre économie unitaire a besoin, (d) correspond au fondateur. Un ICP vague ("quiconque veut le produit") rend chaque résultat ultérieur ambigu et rend les erreurs indiagnosticables. Si l'ICP n'est pas clair, c'est le point d'amélioration n°1.
Étape 2 — Parcourir le cycle de vie
Pour chaque étape, lisez la référence correspondante + la section correspondante de la checklist, puis notez les lacunes.
| Étape | À lire | À rechercher |
|---|---|---|
| Acquisition | references/acquisition.md | Hero échoue au test des 5 secondes, jargon, CTA générique, pas/faible preuve, inadéquation de notoriété, LP qui ne qualifie pas |
| Activation / Onboarding | references/onboarding-activation.md | Pas de moment-aha défini, TTV lent, tableau de bord vide, visite passive, friction admin, écart de parcours |
| Rétention / Churn | references/retention-churn.md | Dette d'attentes, churn par jargon, flux d'annulation mort, modèle de tâche unique, communications réactives, faible adoption de fonctionnalités, pas de boucle d'habitude, pas de fossé |
| Monétisation / Expansion | references/pricing-expansion.md | Pas de leurre/ancre, >4 plans, gratuit ancré à zéro, mauvais défauts, chemin de mise à niveau faible, upsell qui interrompt au lieu de répondre à une limite |
| Métriques / Expérimentation | references/metrics-experimentation.md | Métriques de vanité, tests A/B sous-puissants, LTV mélangée, LTV:CAC gonflé, mathématiques du seau percé ignorées |
| Stratégie produit / conception | references/product-design-strategy.md | Expansion de fonctionnalités (Swiss Knife Index), pas de filtre de fonctionnalités, tableau de bord encombré, refontes cosmétiques uniquement |
Étape 3 — Noter les 9 principes RCD → references/revenue-centric-design.md
Évaluez chaque principe Réussi / Partiel / Échec avec une phrase de preuve. C'est le tableau de bord transversal.
Étape 4 — Exécuter la checklist maître → checklists/master-audit-checklist.md
Le détecteur de lacunes complet et conscient de la phase. Chaque concept du corpus apparaît ici. Chaque élément est une vérification oui/non étiquetée avec son biais/principe et un pointeur vers la référence pour la correction.
Étape 5 — Émettre les résultats → assets/audit-report-template.md
Remplissez le modèle : verdict de phase + ICP, tableau des résultats (zone · résultat · preuve · biais/principe · sévérité · correction · effort×impact), top-5 des gains rapides, tableau de bord RCD.
Navigation — quel fichier répond à quelle question
| Question | Fichier |
|---|---|
| "Que signifie chaque principe RCD et comment le vérifier ?" | references/revenue-centric-design.md |
| "Quel biais s'applique ici / quelle est l'étude derrière ?" | references/cognitive-biases.md |
| "La page d'accueil / hero / copie / CTA / positionnement est-il correct ?" | references/acquisition.md |
| "Pourquoi les essais ne s'activent-ils pas ? Quel modèle d'onboarding convient ?" | references/onboarding-activation.md |
| "Pourquoi les gens se désabonnent-ils ? Comment retenir et construire un fossé ?" | references/retention-churn.md |
| "Comment structurer la tarification / les niveaux / les défauts / les mises à niveau ?" | references/pricing-expansion.md |
| "Cette métrique ou expérience est-elle fiable ?" | references/metrics-experimentation.md |
| "Trop de fonctionnalités ? Tableau de bord encombré ? Que couper ?" | references/product-design-strategy.md |
| "Que dois-je prioriser à mon stade ?" | references/startup-phases.md |
| "Donne-moi la checklist complète." | checklists/master-audit-checklist.md |
Comment rédiger des recommandations
- Soyez spécifique et quantifié. "Remplacez le titre du hero 'A plataforma completa de produtividade' par un nommant l'ICP + le résultat, par exemple 'Contrôle des commandes pour atelier mécanique'" — pas "améliorez le titre."
- Liez chaque résultat à un biais ou principe nommé (par exemple Ancrage, Aversion aux pertes, RCD #6 Défauts). Le "pourquoi" rend une recommandation persuasive et digne de confiance.
- Respectez la phase. Ne recommandez pas l'optimisation de phase d'échelle à un produit en phase de survie. En survie, priorisez la différenciation/confiance/rapidité vers la valeur ; en traction, l'onboarding comportemental et le churn ; plus tard, l'efficacité de rétention et le fossé.
- Préférez les corrections à fort effet de levier aux cosmétiques. La structure de tarification, les défauts et la séquence d'onboarding déplacent les métriques bien plus que la couleur d'un bouton. (1 % de meilleur prix ≈ 8–11 % de profit supplémentaire contre ≈2 % pour une meilleure acquisition de 1 % — ProfitWell.) Signalez le "repeint" déguisé en "refonte."
- Quantifiez la fuite quand vous le pouvez. Utilisez les mathématiques du seau percé et du LTV de cohorte dans
references/metrics-experimentation.mdpour traduire un point de churn en R$.
Porte éthique
La persuasion ici est pour la clarté et l'élan, pas la coercition. Appliquez ces règles ou l'audit devient un manuel de dark patterns :
- Les défauts doivent être éthiquement défendables. Une case pré-cochée qui piège les utilisateurs dans des dépenses est un appât à churn et un risque de réclamation/remboursement — recommandez des défauts qui correspondent à ce qu'un utilisateur informé de l'ICP choisirait.
- La promesse doit égaler la preuve (RCD #4). Ne recommandez jamais une affirmation que le produit ne peut pas démontrer — cela crée une dette d'attentes et provoque le churn.
- La rareté/l'urgence doit être réelle. Recommandez uniquement la rareté honnête (limites réelles, délais réels), jamais de comptes à rebours fabriqués.
- La friction qui qualifie ≠ la friction qui piège. Ajoutez de la friction pour qualifier l'intention ou approfondir l'engagement ; jamais pour obstruer l'annulation.
Référence rapide des benchmarks
Utilisez comme jalons approximatifs (principalement SaaS ; certaines données US — ajustez pour le marché). Sources dans references/.
| Métrique | Faible | OK | Fort | Note |
|---|---|---|---|---|
| Taux d'activation | <20 % | 30–37 % | 40 %+ | <20 % = problème structurel d'onboarding/produit |
| Rétention à J7 | <10 % | 10–15 % | >30 % | |
| Temps vers la valeur (TTV) | jours | ~1j12h (médiane) | <5 min (top) | Userpilot, 547 entreprises |
| NRR (B2B) | <100 % | ~100 % | >110 % | Sépare la croissance de l'entonnoir percé |
| Essai→payant, carte vs sans carte | 8,9 % (sans carte) | — | 31,4 % (avec carte) | Chartmogul 2026, US, 200 produits |
| LTV:CAC | <3:1 | 3:1 | >3:1 | Recalculez par cohorte ; le mélangé surestime de 30–50 % |
| Swiss Knife Index | <0,3 | — | ≥0,3 | fonctionnalités utilisées par >40 % des actifs/30j ÷ total |
| Niveaux de tarification | 1 ou 5+ | — | 3 (2–4 max) | Loi de Hick ; le leurre nécessite un plan intermédiaire |
| Point idéal des avis | 5,0 (semble faux) | — | 4,2–4,5★ | Northwestern |
En citant un nombre, attribuez la source et notez qu'il s'agit d'un benchmark, pas d'une garantie.