Que fait Évaluateur de Monétisation IA ?
Un outil d'aide à la décision pour « dois-je construire ceci pour gagner de l'argent ? » — applique un barème fixe pour que la réponse repose sur la réalité de la demande, pas sur l'enthousiasme.
Inspiré par les modèles répertoriés dans bleedline/aimoneyhunter (une collection populaire en chinois de méthodes de side-hustle IA). Ce skill est un barème original, pas une copie de ce contenu.
Quand l'utiliser
- L'utilisateur propose une idée de produit / side-project / SaaS / extension de navigateur et demande si elle se vendra.
- L'utilisateur veut un verdict « go/no-go » avant d'investir du temps de développement.
- L'utilisateur choisit entre plusieurs directions de monétisation.
- L'utilisateur a un produit existant qui ne génère pas de revenus et veut savoir pourquoi.
Principe fondamental
Le goulot d'étranglement d'un produit rentable n'est presque jamais le code — c'est la demande. La plupart des produits IA qui échouent sont techniquement corrects mais résolvent un problème pour lequel personne ne paie. Évaluez donc la demande avant de vanter la construction.
La question la plus importante, posée en premier, à chaque fois :
« Que fait actuellement l'utilisateur à la place, et pourquoi cette situation est-elle suffisamment douloureuse pour qu'il paie pour l'éviter ? »
S'il n'existe pas de statu quo douloureux, l'idée est un « nice to have » et aura du mal à convertir — dites-le clairement.
Le barème (notez chaque axe de 0 à 2)
Parcourez l'idée à travers cinq axes. Notez honnêtement ; un total élevé avec un zéro honnête sur « solidité de la demande » échoue quand même.
| # | Axe | 0 (rouge) | 1 (ambre) | 2 (vert) |
|---|---|---|---|---|
| 1 | Solidité de la demande | « nice to have », alternatives gratuites partout | léger désagrément récurrent | « impossible de travailler sans » / coûte réellement de l'argent/du temps aujourd'hui |
| 2 | Focalisation sur un créneau | plateforme large (« une IA qui fait tout ») | semi-verticale | un cas d'usage précis pour un utilisateur clair |
| 3 | Disposition à payer | les utilisateurs s'attendent à ce que ce soit gratuit | incertain | des outils comparables facturent déjà et les gens paient |
| 4 | Distribution | « construis-le et ils viendront » | un canal non testé | un canal concret et accessible où l'utilisateur cible se trouve déjà |
| 5 | Avantage concurrentiel | n'importe qui peut le cloner en un week-end | léger avantage | véritable fossé (compétence, accès, données, audience, savoir-faire difficilement acquis) |
Guide de notation :
- 8–10 — Fort. Poursuivez, mais validez d'abord le paiement par un test réel avant de construire en profondeur.
- 5–7 — Mixte. Identifiez l'axe le plus faible et corrigez celui-ci avant de construire davantage. Généralement la demande ou la distribution.
- 0–4 — Faible en l'état. Soit recentrez le créneau/la demande, soit abandonnez. Ne dépassez pas un problème de demande par l'ingénierie.
Workflow
- Reformulez l'idée en une phrase — forcez la clarté. Si vous n'y parvenez pas, l'idée est trop vague pour être évaluée ; demandez à l'utilisateur de la préciser.
- Posez la question centrale (statu quo + douleur). Ne sautez pas cette étape — elle conditionne tout.
- Notez les cinq axes, un raisonnement par axe. Soyez le sceptique, pas le pom-pom boy.
- Nommez l'axe le plus faible — c'est le véritable goulot d'étranglement.
- Donnez 1 à 3 étapes concrètes de validation qui testent l'axe le plus faible à moindre coût (une page d'atterrissage, un MVP manuel, une prévente, un sondage dans la communauté cible) — jamais « construis tout le produit ».
- Verdict : poursuivre / recentrer / abandonner, avec le score total et la première chose à corriger.
Anti-patrons à signaler
- « GPT wrapper pour tout faire » → pas de créneau, pas de fossé. Poussez vers un seul vertical.
- Construire avant de valider la demande → l'erreur la plus coûteuse. Validez d'abord la disposition à payer avec le plus petit test possible.
- Confondre « lancé » avec « découvert » → être sur un app store ≠ avoir des utilisateurs. La distribution est un problème distinct et plus difficile que la construction.
- Prix au jugé → si le prix n'a pas été testé par rapport à un comparable, signalez-le.
- Stratégies limites (revente de clés API/comptes, arbitrage violant les CGU) → signalez le risque de conformité/durabilité ; ne recommandez pas comme activité principale.
Format de sortie
Restez concis :
Idée (une ligne) : …
Statu quo & douleur : …
Notes :
Solidité de la demande X/2 — …
Focalisation créneau X/2 — …
Disposition à payer X/2 — …
Distribution X/2 — …
Avantage concurrentiel X/2 — …
Total : X/10
Axe le plus faible : …
Valider d'abord : 1) … 2) …
Verdict : poursuivre / recentrer / abandonner — corrigez [X] d'abord.