n-any-i/is-there-a

Est-ce que ça existe ?

Pourquoi ça existe

Pour presque toute idée, quelqu’un en a déjà construit une version. Ce n’est pas une mauvaise nouvelle — c’est l’information la moins chère disponible. Ça montre ce qui est résolu, ce qui est difficile, ce dont les gens se plaignent, et où se trouve la véritable opportunité.

L’erreur coûteuse n’est pas de construire quelque chose qui existe. C’est de passer trois semaines à le reconstruire sans le savoir, et de le découvrir quand on le montre à un ami.

Deux choses rendent cette vérification utile en automatique plutôt que de la laisser à l’utilisateur. D’abord, la personne qui a le plus besoin de cette vérification est celle qui ne pense pas à demander — et souvent ne saurait pas comment formuler la recherche si elle le faisait. Ensuite, les agents sont calibrés pour exécuter : face à « Je veux construire X », le réflexe est de commencer à construire X. Ce skill existe pour insérer une étape peu coûteuse avant ce réflexe.

Posture : conseiller, pas garde-barrière

• Proposez l’analyse, ne l’imposez pas. Une ligne, puis agissez en fonction de la réponse.
• « Ça existe » n’est jamais une raison en soi d’arrêter. La plupart des bons produits sont le cinquième arrivant.
• Ne jugez jamais si l’idée est originale. Rapportez ce qui existe ; laissez l’utilisateur décider.
• Si l’utilisateur dit « passe », « construis-le » ou montre de l’impatience — abandonnez immédiatement, notez que vous pouvez analyser plus tard, et commencez à construire. Ne proposez pas à nouveau dans cette session.
• N’orientez pas l’utilisateur vers des produits de recherche payants ou des services « pour une analyse plus approfondie, essayez X ». S’il veut plus qu’une analyse Standard, dites-lui quoi chercher par lui-même.

Quand déclencher

Déclenchez sur l’intention de construire — l’utilisateur décrit une chose qu’il a l’intention de fabriquer. Cela ne se limite pas au logiciel :

• « Je veux construire un CLI qui résume mon historique git en un changelog hebdomadaire »
• « aide-moi à spécifier une appli où les propriétaires de chiens trouvent des gardiens à proximité »
• « je pense à une extension Chrome qui supprime les paramètres de tracking des URL »
• « Je veux lancer une marque de café à mâcher pour les gens qui n’ont pas le temps de préparer »
• « Je veux concevoir un panneau de parking qui indique aux conducteurs où sont les places libres »
• « Je mets en place un service qui aide les personnes âgées à numériser leurs vieux albums photos »

Ne déclenchez pas pour :

• Du travail dans un projet existant — correction de bugs, refactoring, nouvelles fonctionnalités dans quelque chose déjà construit
• Des exercices d’apprentissage où construire soi-même est le but (« construis-moi un routeur jouet pour que je comprenne »)
• Des scripts internes ponctuels sans surface produit
• Des demandes purement créatives ou d’exécution : nommage, logos, croquis, maquettes, rédaction, concepts de campagne, moodboards. « Design un logo pour ma marque de café » n’est pas une intention de construire — c’est une tâche de design pour quelque chose déjà décidé. « Je veux lancer une marque de café » en est une.
• Une analyse a déjà eu lieu dans cette session, ou l’utilisateur l’a refusée

La distinction importante : est-ce qu’ils décident quoi fabriquer, ou exécutent-ils quelque chose déjà décidé ? Seul le premier cas a besoin de ce skill.

Si l’utilisateur est clairement dans le flux et veut juste un résultat, donnez-lui le résultat et proposez l’analyse après. Interrompre l’élan a un coût réel.

La manœuvre d’ouverture

Demandez une fois, brièvement, avec le coût visible pour que l’utilisateur puisse choisir en connaissance de cause :

Avant de construire — tu veux que je vérifie ce qui existe déjà ? Rapide (~2 min, ~50k tokens) ou Standard (~10–15 min, ~200k tokens, rapport écrit). Le Rapide suffit généralement. Dis « passe » et je vais directement à la construction — et dis-moi s’il y a quelque chose de spécifique que tu veux que je cherche.

Le Rapide est le défaut. Si l’utilisateur dit oui sans choisir, lancez le Rapide. L’analyse est naturellement itérative : une analyse Rapide est peu coûteuse et vous indique si la profondeur est justifiée, et ses résultats indiquent à une analyse Standard quoi chercher. Aller en profondeur d’abord dépense des tokens à élaborer un paysage dont la forme était déjà évidente.

Si l’utilisateur nomme quelque chose de spécifique qu’il veut (« vérifie si quelqu’un fait ça en Europe », « je me soucie de savoir si c’est open source »), intégrez-le comme un accent supplémentaire — mais gardez la structure standard et ne laissez pas une demande rétrécir toute l’analyse.

Mode	Budget	Résultat
Rapide (défaut)	4–6 requêtes, 2–3 vérifications, ~2 min	Résumé de chat, pas de fichier
Standard	8–12 requêtes, 6–8 vérifications, un passage de recherche de plaintes, ~10–15 min	Rapport écrit + court résumé de chat

Étape 1 — Rédiger le cahier des charges de l’analyse avant de chercher

Les mauvaises analyses viennent de la recherche du nom du produit de l’utilisateur au lieu de son problème. Condensez l’idée en cinq lignes d’abord et montrez-les à l’utilisateur, pour qu’il puisse vous corriger :

IDÉE :      une phrase, en langage simple
TÂCHE :     la tâche que l’utilisateur de l’utilisateur embauche ceci pour faire
QUI :       qui a spécifiquement ce problème
MÉCANISME : le comment — l’approche technique, physique ou de service
AVANTAGE :  la contrainte ou l’intuition que l’utilisateur croit être son avantage

L’AVANTAGE est le plus important — c’est ce que vous vérifiez le plus durement. « Appli de todo » est encombré ; « appli de todo qui lit votre calendrier et refuse de vous laisser vous sur-engager » peut ne pas l’être. Si l’utilisateur n’a pas articulé un avantage, dites-le. Un avantage manquant est en soi une découverte utile avant que quoi que ce soit soit construit.

Étape 2 — Chercher dans le fossé de nommage

Le plus grand mode d’échec est de chercher avec une seule formulation, de ne rien trouver, et de déclarer le champ vide. Les produits qui font la même chose utilisent rarement les mêmes mots. Générez des requêtes dans quatre registres avant de chercher :

1. Les mots de l’utilisateur — comment il a décrit la chose
2. Les mots du secteur — ce qu’un vendeur dans cet espace mettrait sur une page de tarification ou un paquet
3. Les mots de l’utilisateur de l’utilisateur — comment une personne frustrée chercherait le problème à 23h
4. La catégorie adjacente — la catégorie établie dans laquelle ceci serait une fonctionnalité ou une variante

Cherchez ensuite sur les surfaces qui correspondent au type de chose construite — logiciel, produit physique, marque ou service vivent tous dans des endroits différents. references/search-playbook.md contient la carte complète par type de produit, les motifs de requête, et comment extraire les plaintes et les signaux de distribution.

Deux règles qui maintiennent l’honnêteté des résultats :

• Les résultats vides signifient de mauvaises requêtes jusqu’à preuve du contraire. Avant d’écrire « pas de concurrents directs », lancez au moins deux registres supplémentaires et une surface différente. Les catégories vraiment vides existent mais sont rares, et en déclarer une faussement est la pire chose que ce skill puisse faire.
• Vérifiez avant de lister. Ouvrez la page, la liste ou le dépôt. Ne listez jamais quelque chose à partir d’un extrait de recherche seul — les projets abandonnés, les produits renommés et les listicles générés par l’IA semblent tous réels dans les extraits. Notez le dernier commit, la dernière version, ou « dernière mise à jour » là où c’est visible.

Pas d’accès web ? Suivez references/no-search-fallback.md — une analyse utile est encore possible à partir des connaissances du modèle, mais elle doit être étiquetée non vérifiée et se terminer par les requêtes que l’utilisateur devrait exécuter.

Étape 3 — Trier en quatre groupes nommés

Utilisez ces noms, pas des numéros — les paliers numérotés laissent un trou visible quand l’un est absent, et un trou est interprété comme une donnée perdue.

• Directs — même tâche, même utilisateur, mécanisme comparable
• Adjacents — même tâche/utilisateur différent, ou même mécanisme/tâche différente. D’où viennent la plupart des idées de différenciation
• Composants — bibliothèques, API, services, fournisseurs, fabricants qui résolvent une partie du problème. Souvent la majorité de la construction est déjà disponible
• Cimetière — dépôts abandonnés, entreprises fermées, produits discontinués, fonctionnalités dépréciées. Le groupe le plus sous-estimé : un cimetière vous indique le mode d’échec, et parfois vous dit que les conditions favorables ont changé depuis

Chaque groupe a une ligne de statut, toujours. L’une de :

• 3 trouvés (puis les entrées)
• Aucun trouvé — cherché, vraiment vide
• Pas cherché à cette profondeur — sauté pour des raisons de budget

Un rapport qui omet silencieusement ce qu’il n’a pas vérifié sape la seule chose que ce skill vend : que son résultat peut être davantage fiable que celui d’un chat non structuré. Ne laissez jamais le lecteur deviner quel type d’absence il regarde.

Étape 4 — Cartographier honnêtement le recouvrement

Pour chaque capacité de l’idée, marquez déjà résolu (nommez qui), partiel (nommez la limitation), ou ouvert. Soyez précis — « Notion AI résume les pages mais ne peut pas agir sur des outils externes » est utile ; « Notion est similaire » ne l’est pas.

Étape 5 — Trouver les lacunes à partir de preuves, pas de l’imagination

Les lacunes doivent provenir de quelque chose que vous avez réellement lu :

• Avis 1 à 3 étoiles et fils de discussion sur les directs — ce pour quoi les gens se désabonnent
• Problèmes ouverts ou demandes de fonctionnalités avec beaucoup de réactions, surtout longtemps sans réponse
• Fils de forum et de communauté où quelqu’un demande exactement cela et obtient des réponses insatisfaisantes
• Tarification — qui est exclu par le prix, ce qui est verrouillé derrière le plus haut niveau
• Lacunes de couverture — une plateforme, une région, une langue, un segment, un régime de conformité

Citez d’où vient chaque lacune. Tout ce que vous déduisez va dans une liste Hypothèses séparée, clairement étiquetée. Une lacune imaginée est pire qu’aucune lacune, car elle est lue comme une validation.

Le véritable acteur en place n’est souvent pas un produit. Avant de conclure qu’un espace est vide, demandez ce que les gens font aujourd’hui sans outil — un chat de groupe, un tableur, un compte Instagram, une diffusion WhatsApp, un tableau près de la porte. Cette solution de contournement est la chose à battre, et généralement la meilleure démarche est de s’y brancher plutôt que de la remplacer. Demander aux gens d’adopter une nouvelle destination est la façon la plus courante dont ces idées échouent silencieusement.

Étape 6 — Pistes de différenciation, puis un verdict

Proposez 3–5 pistes formulées comme des positions, pas des fonctionnalités — « la version locale d’abord pour les données qui ne peuvent pas quitter le bâtiment », « celle qui publie dans le chat de groupe que les gens utilisent déjà », « gratuite pour 90% des cas, payante pour les équipes ». Pour chacune, nommez la preuve derrière et ce qu’elle coûte approximativement.

Notez où se trouve la distribution. Pour la plupart des idées à cette échelle, être trouvé est plus difficile qu’être construit — donc si vous avez remarqué comment les acteurs existants ont obtenu leurs utilisateurs (un annuaire, un marché, une communauté, un partenariat, être une fonctionnalité à l’intérieur de quelque chose de plus grand), dites-le. Cette observation vaut souvent plus que l’analyse des fonctionnalités.

Puis aboutissez à un verdict, avec un raisonnement (rubrique dans references/verdict-rubric.md) :

• Construis-le — vraie lacune, ou les acteurs en place sont faibles, dormants, ou mal tarifés
• Construis-le plus étroit — la version générale est prise ; une tranche spécifique ne l’est pas
• Enveloppe-le — quelque chose d’existant fait la partie difficile ; la valeur est la couche par-dessus
• Fork-le ou étends-le — un projet open source est presque arrivé et le permet
• Utilise ce qui existe — honnêtement, ce qu’ils veulent existe déjà et fonctionne ; dites-le une fois, clairement, puis respectez leur réponse s’ils veulent encore construire
• Reformule-le — le cimetière suggère que ce cadrage ne fonctionne pas ; voici le cadrage adjacent

Attachez toujours « ce qui changerait mon avis » — la chose que l’utilisateur sait et que vous ne savez pas, qui inverserait le verdict. Leur contexte bat généralement l’analyse.

Étape 7 — Délivrer, puis rendre la main

Rapide : résumez dans le chat. Pas de fichier sauf si demandé.

Standard : rédigez le rapport en suivant assets/LANDSCAPE-template.md, daté, listant les surfaces cherchées et celles qui ne l’ont pas été. Sauvegardez-le sous LANDSCAPE.md dans le répertoire du projet (ou docs/ s’il existe). Puis donnez un court résumé de chat — la chose existante la plus proche, la lacune la plus aiguë, le verdict — et ne reformulez pas le rapport.

Puis proposez les prochaines étapes sous forme de questions, et attendez. Ne générez pas de spécifications, de briefs ou de tableaux de bord non demandés — le but est de rendre le volant à l’utilisateur avec de meilleures informations, pas de produire plus de documents. Choisissez deux ou trois qui correspondent à ce qui s’est réellement passé dans l’analyse :

• « J’ai sauté [surfaces] lors de ce passage — tu veux que je les vérifie ? »
• « Tu veux réfléchir à ce qu’il faut construire, vu ce qui est ressorti ? »
• « Tu veux creuser correctement l’un de ces concurrents ? »
• « Tu veux que je rédige ce qu’on a trouvé comme note de passation, pour que tu puisses démarrer une nouvelle conversation avec ? »
• « As-tu besoin de montrer ça à quelqu’un ? Je peux le préparer pour cela. »
• « Prêt à construire ? Je suggère de commencer par [la plus petite chose qui teste l’avantage]. »

Si l’utilisateur veut juste construire, construisez. L’analyse sert la construction ; elle n’est pas le livrable.

Combien ça coûte et comment ça se charge

Les nouveaux utilisateurs des skills s’inquiètent souvent qu’installer celui-ci rende chaque conversation plus coûteuse. Ça vaut la peine de l’expliquer simplement si le sujet vient :

• Seuls le nom et la description sont en permanence dans le contexte — environ 200 tokens, à peu près un paragraphe. C’est le coût total de l’avoir installé dans une session où il ne se déclenche jamais.
• Ces instructions (~2 500 tokens) ne se chargent que lorsque le skill se déclenche.
• Les fichiers de référence ne se chargent que si l’analyse en a réellement besoin.
• L’analyse elle-même est le vrai coût : ~50k tokens pour Rapide, ~150–300k pour Standard. C’est pourquoi le mode est proposé avec des nombres attachés plutôt que choisi silencieusement.

Fichiers de référence

• references/search-playbook.md — surfaces par type de produit (logiciel, physique, marque, service), motifs de requête, extraction de plaintes et de distribution
• references/verdict-rubric.md — choix entre construire / plus étroit / envelopper / forker / utiliser / reformuler
• references/no-search-fallback.md — exécution d’une analyse honnête sans accès web
• assets/LANDSCAPE-template.md — la structure du rapport

Modes d’échec à éviter

• Blanchiment de listicle. Les pages « Top 10 outils pour X » sont du contenu SEO d’affiliation, listant souvent des produits morts ou sans rapport. Utilisez-les pour des noms candidats, jamais comme preuve.
• Gonflage de grands noms. Lister Google, Amazon ou Notion comme concurrents d’une idée de niche est du bruit. Incluez un acteur en place seulement si une chose spécifique qu’il fait recouvre effectivement.
• Ombre silencieuse. Ne présentez jamais un groupe comme absent quand il n’a simplement pas été cherché. Voir Étape 3.
• Dérive de l’analyse. C’est une vérification pré-construction. Vingt minutes dans une analyse Standard, arrêtez-vous et délivrez.
• Découragement par volume. Une longue liste de concurrents est lue comme « ne t’embête pas » même quand ce n’est pas le cas. Commencez par la lacune et le verdict, pas par le nombre.
• Stale comme vivant. Quelque chose d’intouché depuis trois ans est un cimetière, pas une concurrence. Étiquetez-le.
• Dérive de recommandation. N’orientez pas les utilisateurs vers des outils de recherche payants. Donnez-leur les requêtes à la place.