Comment j'ai créé 4 outils gratuits qui se classent sur Google et génèrent du trafic SaaS quotidien

Salut !

Je m’appelle Lambert. J’ai 23 ans et je dirige le growth chez Morgen.

Il y a quelques mois, j’ai rejoint mon ancien collègue de Wooclap, Jim Hartung, pour générer du trafic organique sans publicité payante. Morgen est une application de planification et de productivité, Jim avait construit un produit solide, et l’opportunité de croissance était grande ouverte.

La plupart des gens à ma place auraient lancé un blog. Des articles comparatifs. Des listes « Les meilleurs outils X ». Le truc habituel.

Je n’ai pas écrit un seul article.

À la place, j’ai construit des outils gratuits.

4 d’entre eux. Ils se classent tous sur Google. Cette méthode est le processus exact que j’ai suivi : comment je trouve, cadre, construis, lance et améliore des outils gratuits qui génèrent du trafic qualifié pour un produit SaaS.

Chaque chiffre provient de notre Google Search Console. Chaque outil est en ligne, tu peux aller les utiliser dès maintenant.

Nous lançons également en ce moment un nouveau produit appelé Kai, un agent conçu pour faire les choses à la place des gens. Il pourrait changer la façon dont les gens organisent leur travail. Je compte appliquer et étendre cette méthode exacte pour piloter l’acquisition de Kai aussi. Si le système fonctionne pour des outils gratuits sur une application de planification, il devrait fonctionner encore mieux quand le produit lui-même est construit autour de l’IA.

Cette méthode est pour toi si :

• Tu travailles dans le SaaS et veux du trafic organique qui ne dépend pas de la publication d’articles chaque semaine
• Tu as pensé à construire des outils gratuits mais ne savais pas par où commencer
• Tu veux un système, pas une tactique ponctuelle
• Tu es une personne du growth, un marketeur ou un builder qui veut livrer des choses qui se classent

C’est parti.

Partie 1 : Pourquoi construire des outils plutôt qu’écrire des articles ?

Voici comment la plupart des entreprises SaaS font du SEO :

1. Trouver des mots-clés
2. Écrire des articles
3. Publier, optimiser, répéter

Ça marche quand quelqu’un veut apprendre quelque chose.

Mais que se passe-t-il quand quelqu’un veut faire quelque chose ?

Quand quelqu’un tape « scheduling poll » sur Google, il ne veut pas lire un article de 2 000 mots sur ce qu’est un sondage de planification. Il veut créer un sondage. Tout de suite.

Quand quelqu’un tape « timezone meeting planner » sur Google, il ne veut pas un article de blog. Il veut planifier une réunion à travers les fuseaux horaires.

J’appelle ça l’intention-outil vs l’intention-contenu. La plupart des entreprises les traitent de la même façon : elles écrivent des articles pour les deux.

C’est là qu’est la faille.

Comment je décide quoi construire vs quoi écrire

Une seule question :

« Cette personne veut-elle FAIRE quelque chose, ou SAVOIR quelque chose ? »

Si la personne veut…	Donne-lui…	Exemple
FAIRE quelque chose	Un outil gratuit	« scheduling poll », « calendar link generator »
SAVOIR quelque chose	Un article	« how to run better meetings »

Si l’intention est « faire » et que tu donnes un article, tu as déjà perdu. Tu amènes un article de blog dans un combat d’outils.

Pourquoi c’est possible maintenant

Construire des outils nécessitait autrefois des sprints d’ingénierie. Des semaines de travail. Même si tu savais qu’un outil surpasserait un article, le coût était trop élevé pour qu’une équipe growth le justifie.

Ça a changé. Pas parce que « l’IA écrit du code maintenant », c’est la version simpliste.

Ce qui a réellement changé, c’est ceci : les opérateurs growth peuvent désormais construire des choses qui n’ont pas besoin de vivre à l’intérieur du produit principal.

Si un utilitaire est adjacent à ton SaaS mais n’a pas besoin de comptes utilisateurs, de bases de données ou d’une logique backend profonde, il peut souvent être construit comme un outil autonome sur ton site web. Un sondage de planification. Un convertisseur de fuseaux horaires. Un générateur de liens de calendrier. Ce ne sont pas des fonctionnalités produit. Ce sont des utilitaires de site web qui résolvent de vrais problèmes liés à ton espace produit.

C’est là qu’est le levier.

Des outils comme Claude Code rendent cela possible parce qu’ils comprennent le contexte. Tu peux leur fournir ta connaissance produit, tes données de mots-clés, ton design system, et ils t’aident à raisonner sur quoi construire, comment le cadrer et comment le livrer. Ce n’est pas « l’IA génère un site web ». C’est : une personne du growth avec du contexte produit peut désormais construire et livrer des outils utiles sans attendre dans une file d’ingénierie.

Ça ne veut pas dire qu’on n’a plus besoin de développeurs. Ça veut dire que les marketeurs et les opérateurs growth peuvent livrer de façon autonome pour une classe spécifique d’initiatives, celle où le résultat est un utilitaire autonome sur le site web, pas une fonctionnalité à l’intérieur du produit.

	Avant	Maintenant
Article	1 jour	1 jour
Outil	2 à 4 semaines (besoin d’ingénierie)	1 à 5 jours (le growth peut le livrer)

Quand construire un outil prend des jours au lieu de mois, le SEO cesse d’être un jeu de contenu. Il devient un jeu de produit.

Les outils composent différemment des articles

Les articles se dégradent. Tu arrêtes de les mettre à jour, les classements glissent.

Les outils, c’est différent. Les gens les mettent en favoris. Les gens y font des liens depuis leurs propres blogs. Les gens les partagent avec leurs collègues. Chaque session utilisateur envoie des signaux d’engagement à Google.

Un bon outil devient plus fort avec le temps parce que les gens l’utilisent réellement.

À retenir : Pour les mots-clés à intention-outil, construis un outil. Pour les mots-clés à intention-contenu, écris un article. La plupart des entreprises se rabattent sur les articles pour tout. C’est ton ouverture.

Partie 2 : Comment je trouve les bonnes opportunités d’outils

Le processus est construit autour de Claude

Je ne commence pas par un brainstorm dans un tableur. Je commence par le contexte.

Mon processus utilise Claude Code comme couche de raisonnement centrale. Voici ce que je lui fournis :

• Le codebase de l’application : pour qu’il comprenne ce que le produit fait réellement
• La connaissance produit interne : docs, specs de fonctionnalités, positionnement, parcours utilisateurs
• Les données Ahrefs via MCP : volumes de mots-clés, scores de difficulté, analyse des SERP, métriques concurrentielles
• Reddit et les forums : les vrais points de douleur des utilisateurs, la façon dont les gens parlent du problème

Ensuite, je donne à Claude un brief clair : identifier des opportunités d’outils gratuits qui sont stratégiquement utiles pour notre espace produit. Pas des utilitaires aléatoires. Des outils qui créent un pipeline : quelqu’un utilise l’outil gratuit, et l’expérience donne le sentiment d’être connectée à ce que le produit complet pourrait faire pour lui.

Même si l’outil gratuit ne vit pas à l’intérieur du produit aujourd’hui, il doit donner l’impression d’appartenir au même écosystème.

Ce que Claude fait réellement émerger

Avec le contexte produit + les données de mots-clés + les patterns de SERP, Claude peut identifier des opportunités que je manquerais tout seul.

Il regarde :

• Ce que les gens recherchent dans notre espace produit
• Lesquelles de ces recherches ont une intention-outil
• Là où les résultats existants sont faibles, exigent une connexion ou ont une mauvaise UX
• Ce que nous pourrions construire qui ajoute de la valeur que la SERP actuelle n’offre pas

Je valide aussi avec Reddit et des sources similaires, en vérifiant si de vraies personnes demandent réellement ces outils, ce qui les frustre dans les options existantes, et quelles alternatives gratuites existent (pas seulement des outils payants).

Le résultat réel de mon brainstorm

Voici à quoi ressemblait la liste filtrée. Ce sont de vraies données issues d’Ahrefs :

Idée	Volume (Global)	KD	Intention	Ce que j’ai fait
Scheduling poll	3,800	51	Outil	Construit
Timezone meeting planner	4,000	52	Outil	Construit
Calendar link generator	Moyen	Faible	Outil	Construit
Schedule builder	70K large / 1K ciblé	50	Outil	Construit
Focus timer	3,000	44	Outil	Trop concurrentiel (pomofocus, marinara)
Eisenhower matrix tool	5,000	56	Outil	Trop concurrentiel (Notion, Miro)
Energy planner	800	28	Info	Confondu avec les panneaux solaires
Task roulette	~100	90	Outil	Pas de volume de recherche
Screen time tracker	500	60	Outil	Trop de travail de dev pour trop peu de trafic
Weekly planning template	700	28	Outil	Pas encore assez de volume

J’ai commencé avec plus de 20. J’ai fini par en construire 4.

C’est tout l’enjeu. On ne construit pas tout. On filtre sans pitié.

Partie 3 : Comment je priorise quoi construire en premier

C’est là que la plupart des gens se plantent. Ils choisissent l’idée qu’ils préfèrent ou celle qui sonne le plus cool.

Ne fais pas ça. Choisis l’idée que les données soutiennent.

Je priorise sur 3 leviers :

1. Trafic / demande de recherche : y a-t-il un volume significatif derrière ce mot-clé ?
2. Difficulté du mot-clé / opportunité de classement : pouvons-nous réalistement nous classer dessus ?
3. Vitesse / simplicité de construction : puis-je livrer ça assez vite pour créer de l’élan ?

Le meilleur premier outil réunit les trois : un vrai potentiel de trafic, un mot-clé sur lequel on peut se classer et un temps de construction rapide.

Pourquoi j’ai commencé par le Timezone Meeting Planner

Pas le plus gros mot-clé. Pas l’idée la plus cool. Mais le meilleur premier coup.

• Potentiel de trafic : 4,000 recherches mensuelles dans le monde, solide cluster de mots-clés autour des requêtes liées aux fuseaux horaires
• Difficulté du mot-clé : 52, faisable pour notre autorité de domaine (DR 72)
• Vitesse de construction : j’ai construit la version de base en moins d’une journée

Ce dernier point compte. Le premier outil doit être une victoire rapide. Tu veux prouver que le système fonctionne avant de t’engager dans des constructions plus difficiles.

Tout ce qui entourait la construction de base a pris plus de temps : configuration SEO, finitions de design, page de destination, revue interne. Mais l’outil fonctionnel était en ligne rapidement. Ça m’a donné de l’élan et la confiance pour attaquer les suivants.

Pourquoi le Scheduling Poll et le Schedule Builder sont venus plus tard

Le Scheduling Poll avait de bons chiffres (3,800 de volume, KD 51) mais nettement plus de complexité. Il fallait des liens partageables, une logique de vote, la gestion de plusieurs dates/heures. Ça a fini par être la plus longue construction, environ une semaine.

Le Schedule Builder avait un énorme volume large (70K pour « schedule builder ») mais le cluster ciblé était plus petit. C’était aussi une implémentation plus lourde : glisser-déposer, blocs visuels, mise en page responsive.

Les deux étaient de bonnes opportunités. Mais aucun n’était le bon premier outil. Commencer par eux aurait signifié passer une semaine avant de voir le moindre résultat. Commencer par le Timezone Meeting Planner signifiait avoir un outil en ligne et bien classé en quelques jours.

Ce que j’ai abandonné et pourquoi

• Focus timer : 3K de volume, KD 44. Ça a l’air faisable, mais pomofocus.io et marinaratimer.com possèdent déjà cet espace. Les mots-clés principaux ont un KD très élevé, et les accessibles n’ont presque pas de volume. Mauvais ratio.
• Eisenhower matrix tool : 5K de volume, KD 56. Il y a de la traction, mais Notion et Miro se classent déjà. De gros noms avec un énorme DR. Pas la peine de se battre.
• Energy planner : 800 de volume, KD 28. Le KD faible est tentant, mais la moitié des résultats de recherche concernent les panneaux solaires. Le concept est aussi difficile à construire simplement.
• Screen time tracker : il aurait fallu construire une extension Chrome. Trop de travail de dev pour 500 recherches mensuelles.

À retenir : Le meilleur premier outil est celui qui a un fort trafic, une difficulté sur laquelle on peut se classer et une construction rapide. Ne commence pas par le plus dur ou le plus cool, commence par celui qui prouve que le système fonctionne.

Partie 4 : Cadrer le MVP

C’est l’une des parties les plus importantes du processus. Et ça ne commence pas par des wireframes ou des listes de fonctionnalités.

Ça commence par construire le bon environnement de travail pour Claude Code.

Mettre en place l’environnement de construction

Avant de construire quoi que ce soit, je prépare :

• Un solide CLAUDE.md : c’est le fichier d’instructions qui donne à Claude tout le contexte dont il a besoin sur le projet, les contraintes et les attentes
• De la documentation : doc de cadrage du MVP, ce que l’outil doit et ne doit pas faire
• Des règles de design : couleurs, typographie, patterns de composants, espacements
• Des contraintes d’implémentation : stack, framework, quelles librairies utiliser ou éviter
• Des contraintes de déploiement : où ça sera hébergé, comment ça passe en ligne

Ce dernier point est critique. Si tu ne spécifies pas les contraintes de déploiement dès le départ, tu rencontreras des conflits plus tard. Dans mon cas, j’utilise GitHub avec GitHub Actions / Pages, puis certains outils sont poussés dans Webflow selon la configuration. D’autres personnes utiliseront peut-être Vercel ou Netlify, l’important c’est : décide-le en amont.

L’analyse concurrentielle façonne le MVP

Pour chaque outil, je collecte ce que font les 5 meilleurs concurrents sur la SERP.

Je demande :

• Quelles fonctionnalités ont-ils tous ?
• Qu’est-ce qui est faible, manquant ou frustrant ?
• Qu’est-ce qui n’est pas différencié : que font-ils tous de la même manière ?
• Où pouvons-nous ajouter de la valeur qu’ils n’apportent pas ?

Claude aide à traiter ça rapidement. Donne-lui les URL des concurrents et les données de SERP, et il peut identifier les failles en quelques minutes.

À partir de cette analyse, le MVP prend forme, non pas à partir de l’imagination, mais à partir de ce qui manque sur le marché.

La prépa SEO et design se fait en parallèle

En même temps que le cadrage du MVP :

• Je demande à Claude de lancer une analyse SEO complète pour l’outil et son cluster de mots-clés
• Je prépare la documentation MVP : ce que l’outil fait, le parcours utilisateur, les cas limites
• Je prépare la documentation SEO : mots-clés cibles, structure de page, balises meta, plan de maillage interne
• Je prépare les directives de design : cohérentes avec les patterns existants

Côté design, j’importe le codebase du SaaS et le contexte du site web / Webflow. Ça aide Claude à rester cohérent avec les patterns de design existants et la logique front-end. L’outil doit donner le sentiment d’appartenir au site, pas d’être un projet annexe aléatoire.

Ce que j’ai réellement livré en v1

Timezone Meeting Planner v1 :

• Comparer les horaires à travers plusieurs fuseaux pour trouver les disponibilités qui se chevauchent
• Pas de fonctionnalités d’équipe, pas d’intégration, pas de préférences sauvegardées
• Temps de construction : moins d’1 jour (version de base)

Calendar Link Generator v1 :

• Générer des liens de calendrier Google / Outlook / Apple à partir des détails d’un événement
• Pas d’événements récurrents, pas de détection automatique de fuseau, pas d’historique sauvegardé
• Temps de construction : ~1 jour

Schedule Builder v1 :

• Construire un planning hebdomadaire visuellement avec des blocs en glisser-déposer
• Pas de sauvegarde, pas de partage, pas d’export vers le calendrier
• Temps de construction : ~2 jours (puis amélioré sur plusieurs semaines)

Scheduling Poll v1 :

• Créer un sondage avec des options de date/heure, partager un lien, laisser les gens voter
• Pas de comptes, pas de rappels par e-mail, pas d’intégration calendrier
• Temps de construction : ~1 semaine (le plus complexe des quatre)

À retenir : Expédie la plus petite chose qui répond à l’intention de recherche. Cadre-la à partir des failles des concurrents, pas de listes de souhaits de fonctionnalités.

Partie 5 : Construire et déboguer

Le workflow de construction

Une fois toute la prépa terminée, CLAUDE.md, docs, règles de design, contraintes de déploiement, la construction proprement dite va vite.

Mon workflow :

1. Je demande souvent à Claude Code de préparer un lot de prompts pour les différents composants
2. Parfois j’automatise l’exécution des prompts avec des scripts pour que plusieurs étapes tournent pendant que je travaille sur autre chose
3. Je passe en revue le résultat, je le teste, je lui dis ce qui ne va pas
4. J’itère

Oui, ça coûte des tokens. Mais ça accélère l’exécution de façon significative. Le travail de prépa paie ici, parce que Claude a tout le contexte dont il a besoin, la qualité du résultat est bien plus élevée que si tu disais juste « construis-moi un sondage de planification ».

Vrais délais de construction

Outil	Temps de construction (base)	Temps total avant lancement
Timezone Meeting Planner	< 1 jour	Quelques jours
Calendar Link Generator	~1 jour	~1,5 jour (plus rapide parce que j’avais de l’expérience à ce moment-là)
Schedule Builder	~2 jours	Plusieurs semaines d’amélioration
Scheduling Poll	~1 semaine	Le plus long, beaucoup plus de complexité

Le Calendar Link Generator a été le plus rapide en partie parce que c’est un outil plus simple, mais aussi parce que j’avais déjà construit le workflow, l’environnement et la mémoire musculaire des outils précédents.

Ce qui a cassé

Je ne vais pas faire semblant que ça a été fluide.

Les bugs arrivent constamment :

• Bugs d’UI : éléments qui se chevauchent, espacements qui cassent, états qui ne se mettent pas à jour
• Bugs de comportement : erreurs de logique dans la conversion de fuseaux, cas limites du vote des sondages
• Problèmes mobiles : c’est souvent la partie la plus dure. Certains outils sont réellement difficiles à faire bien fonctionner sur mobile. Des mises en page qui semblent correctes sur desktop cassent complètement sur les écrans plus petits.
• Problèmes de déploiement / push : si la structure du projet n’est pas propre ou si la config de déploiement ne correspond pas à ce que tu as construit, les choses cassent au moment du push

Le débogage est essentiel et prend un vrai temps.

Une fois une construction prête, je la partage en interne avec l’équipe. Puis on débogue ensemble. Cette phase peut prendre 1 heure, 2 heures, ou plus de 5 heures selon l’outil. Ce n’est pas optionnel, c’est là que l’outil passe de « ça marche techniquement » à « c’est réellement utile ».

Le Scheduling Poll a eu de loin le plus de débogage. Liens partageables, comptage des votes, gestion des fuseaux entre participants, chacun de ces points a créé des cas limites.

Le Schedule Builder a eu de pénibles problèmes mobiles. L’interface de glisser-déposer qui fonctionnait bien sur desktop a nécessité un remaniement important pour les écrans tactiles.

Là où j’ai passé le plus de temps : pas sur la génération de code. Sur les décisions produit et le débogage. Que doit faire l’outil ? Que doit-il NE PAS faire ? Pourquoi c’est cassé sur Safari ? Pourquoi ça s’affiche mal sur un iPhone SE ?

L’IA gère l’implémentation. Tu gères le jugement et les tests. C’est ce partage qui rend possible, pour une personne du growth, de livrer des outils sans équipe d’ingénierie.

Partie 6 : Lancer l’outil avec le SEO

Assets et page de destination

Je prépare généralement les assets manuellement. Je passe environ 2 heures par outil à créer des images, des vidéos et des visuels d’accompagnement. Je tiens à rendre la page de destination forte et soignée, c’est la première impression à la fois pour les utilisateurs et pour Google.

J’utilise souvent Webflow, ou des blocs codés avec Claude alignés sur mon codebase Webflow. La page doit donner l’impression d’appartenir au site, pas d’être un projet de hackathon.

Structure de page SEO

Pour le contenu SEO, je demande à Claude de réutiliser l’analyse de mots-clés d’origine et de m’aider à préparer :

• Une formulation alignée sur l’intention de recherche
• Une structure de page optimisée pour le cluster cible
• Une base de contenu SEO (pas la finition finale, mais la structure)

Ma structure de page habituelle :

1. L’outil d’abord : l’outil fonctionnel est en haut. L’utilisateur est venu pour FAIRE quelque chose.
2. H1 : correspond au mot-clé principal et à l’intention
3. H2 expliquant comment ça marche : des étapes simples et claires
4. Sections H2/H3 autour du problème qu’il résout : pourquoi cet outil existe, à quelle douleur il répond
5. FAQ : ciblant les requêtes longue traîne et les questions « Autres questions posées »
6. Bloc de maillage interne : liens vers les autres outils gratuits

Ce bloc de maillage interne est important. Il connecte les outils stratégiquement : quelqu’un qui a utilisé le sondage de planification pourrait aussi avoir besoin d’un générateur de liens de calendrier. Chaque outil envoie de l’autorité et du trafic aux autres.

Les bases du SEO qui font réellement bouger les classements

Title de la page : inclus le mot-clé principal, garde sous 60 caractères. Exemple : « Free Scheduling Poll, Create a Poll in Seconds »

Meta description : décris ce que fait l’outil + un bénéfice. Sous 155 caractères. Exemple : « Create a free scheduling poll and share it with your team. Find the best time to meet in minutes. »

Titre H1 : correspond à l’intention de recherche. « Free Scheduling Poll » : oui. « Our Polling Solution » ou « Morgen Poll Tool v2 » : non.

URL : propre et riche en mots-clés. /scheduling-poll : oui. /tool-v2-final ou /tools?id=382 : non.

Vitesse de la page : les pages d’outils doivent se charger vite. Les utilisateurs venus de Google rebondissent en 3 secondes. Teste avec PageSpeed Insights, vise 90+ sur mobile.

Faire le lien vers ton produit

Chaque outil doit faire un lien vers ton produit principal. Mais en douceur.

Ce qui marche :

• « Built by Morgen » dans le footer
• Une petite bannière : « Need a full scheduling solution? Try Morgen »

Ce qui ne marche pas :

• Une popup demandant aux utilisateurs de s’inscrire
• Exiger un compte pour utiliser l’outil
• Des CTA qui interrompent l’expérience

Le rôle de l’outil est de servir l’intention de recherche. Si l’outil est bon, les gens seront curieux de savoir qui l’a construit.

Partie 7 : Boucles de feedback

Une part majeure de l’amélioration à la fois des classements et de l’utilité de l’outil consiste à mettre en place une boucle de feedback. Ce n’est pas du support client. C’est une boucle d’amélioration du classement et du produit.

Comment je collecte le feedback

Reddit : je poste l’outil dans les subreddits pertinents et je demande des retours honnêtes. Les gens sur Reddit sont directs, ils te diront ce qui est cassé, ce qui est confus et ce qui manque.

Prompts de feedback sur la page : j’intègre une popup conversationnelle / un prompt de feedback directement sur la page de l’outil. Mais je ne l’affiche pas immédiatement. Je le déclenche généralement après environ 20 secondes, comme ça je sais que la personne a réellement interagi avec l’outil ou la page. Les visiteurs aléatoires qui ont rebondi en 3 secondes ne sont pas sollicités.

Les gens qui prennent le temps d’écrire un feedback réfléchi après avoir utilisé l’outil, ce sont eux qui donnent les insights les plus précieux.

Ce que je fais du feedback

1. Lire tout
2. Identifier les patterns, si 3 personnes mentionnent la même friction, c’est un vrai problème
3. Implémenter le changement
4. Idéalement, répondre à la personne et lui dire que le changement est en ligne
5. Obtenir un nouveau tour de retours

Cette dernière étape compte. Quand quelqu’un voit son feedback implémenté et répond à nouveau, tu obtiens une deuxième couche d’insight. Il remarquera des choses qu’il n’avait pas mentionnées la première fois.

Pourquoi c’est une boucle de classement

De petites améliorations basées sur de vrais retours → meilleure UX → sessions plus longues, taux de rebond plus bas → meilleurs signaux d’engagement → meilleurs classements.

Ce n’est pas spectaculaire. Un changement ne te fera pas bondir de la position #20 à la #3. Mais l’effet cumulé d’améliorations continues, pilotées par le feedback, c’est ce qui sépare les outils qui plafonnent des outils qui continuent de grimper.

Partie 8 : Analyse des données

Ce que je suis

Google Search Console :

• Impressions : les gens voient-ils l’outil dans les résultats de recherche ?
• Clics : cliquent-ils pour accéder ?
• CTR : le titre/la description sont-ils convaincants ?
• Position moyenne : où nous classons-nous, et est-ce que ça s’améliore ?

Plausible :

• Temps sur la page : les gens utilisent-ils réellement l’outil ou rebondissent-ils ?
• Objectifs / événements personnalisés : c’est là que ça devient intéressant
• Patterns d’engagement : que font réellement les utilisateurs sur la page ?

Les objectifs personnalisés comptent

Sur le Scheduling Poll, j’ai mis en place des objectifs qui me permettaient de savoir :

• Combien de personnes ont créé un sondage
• Combien de personnes ont interagi avec un sondage donné (voté, consulté les résultats)

Ça a créé de l’insight pas seulement pour le SEO, mais pour la réflexion produit future. Si des milliers de personnes créent des sondages de planification via notre outil gratuit, c’est un signal sur ce que le produit complet devrait prioriser.

Analyse hebdomadaire / mensuelle

J’utilise des rapports pour comparer :

• Feedback reçu + changements produit effectués
• Variations de performance (impressions, clics, position)
• Ce qui s’améliore et ce qui stagne

L’objectif est de relier cause et effet. Le changement d’UX que j’ai fait le mois dernier a-t-il réellement fait bouger les choses ? La nouvelle section FAQ a-t-elle apporté du trafic longue traîne ?

Automatise ton reporting

Mets en place des rapports hebdomadaires automatisés qui vont sur Slack, par e-mail, ou quel que soit l’outil que ton équipe utilise. J’ai construit un bot qui poste tous les lundis : le trafic par outil, les conversions, les variations en glissement hebdomadaire, et qui signale tout ce qui décline.

Ne compte pas sur quelqu’un pour ouvrir un dashboard. Pousse les données là où l’équipe vit déjà. Quand les gens voient « +28% sur Schedule Builder » dans Slack, ils s’en soucient davantage. Quand le Timezone Meeting Planner chute de 23%, je l’attrape le lundi matin au lieu de le découvrir des semaines plus tard.

J’ai construit le mien avec Claude Code en quelques heures, un script qui tire de Plausible et poste sur Slack via webhook. Simple, ROI élevé.

Partie 9 : Distribution

Le timing compte

Je ne veux pas parler d’un outil trop tôt.

Je préfère attendre jusqu’à ce que :

• L’outil ait vécu un peu
• Je puisse voir s’il répond réellement à un besoin
• Les principaux bugs soient corrigés
• L’expérience soit assez propre pour être montrée publiquement

« J’ai construit un truc et voici ce qui s’est passé » bat « J’ai construit un truc ». Quand tu racontes l’histoire, tu veux de vraies données et une expérience soignée derrière.

Où je distribue

Reddit, canal principal

Je m’engage dans les subreddits où des outils similaires ou des problèmes connexes sont discutés. Un angle différent par subreddit. Ne fais pas de copier-coller.

Subreddit	Angle
r/SaaS	Stratégie de croissance avec des données
r/SEO	Outil vs article, l’approche product-led
r/startups	Croissance sans publicité payante
r/EntrepreneurRideAlong	Histoire de builder

Règles Reddit : commence par l’histoire et les données, pas le produit. Mets les liens à la fin. Réponds à chaque commentaire. Ne mentionne pas ton entreprise dans le titre.

LinkedIn

L’audience des builders réagit aux vraies données et au processus. Je partage l’histoire, les chiffres et l’approche. Cette méthode a démarré comme du contenu LinkedIn.

Collecte continue de feedback

La distribution n’est pas que de la promotion. Chaque fois que je partage un outil, je demande aussi : est-ce que ça fonctionne pour toi ? Qu’est-ce qui manque ? Qu’est-ce qui est confus ?

Rendre l’outil « vivant » signifie le garder dans la conversation, pas juste publier un lien et passer à autre chose.

Ce que je n’ai pas testé

Je n’ai pas sérieusement testé Twitter / X pour ce type de contenu. Je ne vais pas prétendre que j’ai des données là-dessus.

Partie 10 : Résultats

Mis à jour le 1er avril 2026 → voici les vrais chiffres après ~3 mois de mise en ligne des outils gratuits.

Vue d’ensemble du trafic (déc. 2025 – avr. 2026)

6,131 visiteurs uniques sur les 4 outils. Croissance de quasi-zéro en décembre à plus de 200 visiteurs quotidiens fin mars.

Calendrier de lancement :

• 28 déc. 2025 → Timezone Meeting Planner
• 20 janv. 2026 → Schedule Builder
• 8 févr. 2026 → Calendar Link Generator
• 26 févr. 2026 → Scheduling Poll

4 outils livrés en 2 mois.

Trafic par outil

Outil	Visiteurs uniques	Date de lancement
Schedule Builder	2,387	20 janv.
Timezone Meeting Planner	1,543	28 déc.
Scheduling Poll	1,372	26 févr.
Calendar Link Generator	829	8 févr.

Sources de trafic

Source	Visiteurs
Google	3,300 (55%)
Direct / Aucune	1,900 (32%)
ChatGPT.com	415 (7%)
Bing	82
DuckDuckGo	77
Autres	~100

La surprise : ChatGPT.com est notre source de trafic n°3. Ces outils ne se classent pas seulement sur Google → ils sont recommandés par l’IA. Je n’ai pas optimisé pour ça. C’est arrivé parce que les outils résolvent clairement de vrais problèmes.

Tunnel de conversion (Amplitude)

À partir des 4 pages d’outils :

• 291 utilisateurs se sont connectés (depuis les visites des outils gratuits)
• 111 ont complété l’onboarding
• 1 abonnement payant (depuis le Scheduling Poll, le 25 mars 2026) → soit 180 $/an d’ARR issu d’une seule conversion d’outil gratuit

C’est bien ça → notre premier client payant est venu d’un outil gratuit. Le parcours de conversion complet : visite de l’outil gratuit → connexion → onboarding → abonnement.

Ce n’est qu’une personne. Mais ça prouve que le système fonctionne de bout en bout. Les outils gratuits peuvent générer de vrais revenus, pas seulement du trafic.

Métriques d’engagement clés

• Taux de rebond : 71%
• Profondeur de défilement : 27%
• Temps sur la page : 1m 45s

Le taux de rebond est élevé, mais c’est attendu pour des outils → beaucoup de gens utilisent l’outil et repartent. Ce qui compte, c’est les 29% qui s’engagent plus profondément, et le temps moyen de 1m 45s qui montre un usage réel.

Et après

Le système fonctionne. Les chiffres sont petits mais croissent vite → la courbe est exponentielle, pas linéaire. Prochaines priorités :

• Améliorer le taux d’activation (291 connexions → 111 onboardés = 38%. Bien, mais peut être mieux)
• Plus d’outils dans le pipeline
• Appliquer la même méthode à Omnia

Le système

D’autres outils arrivent. Mais le système compte plus que n’importe quel outil isolé.

1. Trouver des mots-clés à intention-outil dans ton espace produit
2. Utiliser le contexte produit + les données de mots-clés pour identifier les opportunités
3. Prioriser par trafic, difficulté et vitesse de construction
4. Cadrer le MVP à partir des failles des concurrents
5. Construire vite avec l’IA, déboguer en profondeur
6. Lancer avec un SEO solide et une page soignée
7. Collecter le feedback, améliorer, mesurer
8. Distribuer quand l’outil est prêt, pas quand il est nouveau
9. Répéter

Si tu es une personne du growth, un marketeur ou un builder dans une entreprise SaaS qui réfléchit au trafic organique, c’est peut-être le levier le plus puissant que tu n’as pas encore essayé.

À propos de Morgen

Morgen est une application de planification et de productivité. Les outils gratuits sont une pièce de notre façon de penser le growth.

Nous construisons aussi Kai, un agent IA qui fait les choses à la place des gens. Même méthode de growth, nouveau produit.

Suis l’aventure :

• LinkedIn : Lambert Le Court De Beru
• Morgen
• Kai

Merci d’avoir lu

Ce n’est pas de la théorie. C’est un processus documenté, issu de la construction de vrais outils dans une vraie entreprise.

Si c’était utile, partage-le avec quelqu’un qui repense son approche du SEO.

Des questions ? Écris-moi sur LinkedIn, je serai ravi d’aider.