jmdevilleros/niche-map

Niche map : lacunes dans un espace conceptuel

Cette compétence trouve des lacunes bien fondées dans un domaine. Elle transforme un paysage flou en un tableau d'éléments réels × dimensions explicites , recherche les combinaisons et les zones que personne n'occupe, traduit ces lacunes en idées concrètes et vérifie qu'il ne s'agit pas de mirages.

Principe directeur. Les chiffres organisent le jugement ; ils ne le remplacent pas. Les codes sont des décisions de l'analyste, donc l'espace reflète autant la grille que le marché. C'est pourquoi chaque lacune proposée doit survivre à un contrôle de fiabilité sur les codes (étape 2b) et à une validation externe (étape 6).

Outils de ce dépôt

Fichier	Rôle
niche_core.py	Étapes 3-4 : encodage, clusters, ACP, UMAP, lacunes de triplets, lacunes de densité, voisins candidats, offre vs demande, figures
recode_check.py	Étape 2b : feuille d'échantillonnage de recodage en aveugle et accord par dimension (kappa de Cohen)
md_to_pdf.py	Étape 7 : conversion du rapport Markdown en PDF
templates/report_template.md	Étape 7 : squelette du rapport
examples/	Ensemble de données synthétiques et fictives pour tester le pipeline de bout en bout

---

0. Entrées et questions de cadrage

Obtenez ces réponses avant de commencer. Si une réponse manque, demandez-la une fois, en un seul bloc.

Entrée	Question	Pourquoi c'est important
Sujet et périmètre	Qu'est-ce qui compte comme élément ? (par exemple, "outils dont la valeur principale est X")	Empêche les catégories mixtes et les artefacts de lacunes.
N	Combien d'éléments ? (par défaut 80-100 ; minimum utile ≈ 50)	Avec N < 50, les comptages de triplets sont du bruit.
Critères d'inclusion	Réception minimale, disponibilité, plateforme, langue, date	Appliqué à l'étape 1 et documenté.
Utilisateur cible	Qui va construire ou acheter ce qui en sortira ?	Base du score d'adéquation et de target_filter.
Contraintes	Budget, heures, compétences, canal de vente, sujets exclus	Deviennent target_filter et le critère d'adéquation.
Livrable	Langue, devise (et source du taux de change), format	Par défaut : PDF avec classement, fiches de niche, cartes et le tableau complet du corpus avec liens.

1. Corpus : N éléments réels et vérifiés

1. Graine large. Collectez environ 1,3 × N candidats provenant de sources variées : magasins ou répertoires de domaine, listes "best of", recherches "alternative à X" et lancements récents de longue traîne (sites de lancement, répertoires de niche, registres open source). Si seuls les produits célèbres entrent, de fausses lacunes apparaîtront plus tard.
2. Vérification d'existence par élément. Chaque élément a besoin d'une URL qui se résout : page de magasin, page de tarification ou dépôt. Enregistrez le statut HTTP, l'URL finale et la date. Si un site bloque les robots (403), vérifiez la racine du domaine ou utilisez un navigateur ; un blocage ne signifie pas que l'élément n'existe pas.
3. Signal de réception. Enregistrez un ou plusieurs signaux publics (note du magasin et nombre d'avis, votes du site de lancement, étoiles du dépôt, installations, récompenses) et déclarez la source et la couverture de chacun. Ne supprimez pas un élément uniquement parce qu'il n'a pas de signal. Si la réception est un critère d'inclusion, appliquez-la avec un seuil explicite.
4. Dédoublez les variantes, les renommages, les éditions et les SKU régionaux. Conservez le nom canonique et les liens.
5. Exclure par périmètre les éléments qui ne satisfont pas aux critères d'inclusion, et listez-les dans le rapport avec la raison.
6. Vérifications des biais du corpus (écrivez les réponses dans le rapport) :
   • Part des éléments de la longue traîne (par exemple, lancés au cours des 24 derniers mois, ou en dessous du signal de réception médian). Si elle est inférieure à ~20%, échantillonnez plus d'éléments de longue traîne.
   • Concentration des sources : aucune source unique ne doit contribuer à plus de ~40% des éléments.
   • Biais de plateforme ou de langue par rapport au périmètre déclaré.
   • Couverture du signal par source (certaines sources surreprésentent certains types d'utilisateurs, par exemple les outils de développement sur les sites d'hébergement de code).

Sortie : items.csv, une ligne par élément avec des colonnes d'identification et de lien, plus un JSON brut de la vérification.

2. Dimensions, échelles et grille de codage

1. Dérivez 8 à 15 dimensions en lisant un échantillon d'environ 20 éléments. Divisez-les en deux types :
   • Dimensions conceptuelles disent ce qu'est l'élément : verbe ou action, entrée, sortie, déclencheur, domaine ou thème, utilisateur, esthétique. Les lacunes sont recherchées avec celles-ci (gap_dims).
   • Dimensions d'attribut disent comment il est construit ou vendu : complexité, étendue, libre-service, modèle de tarification, niveau de prix. Elles filtrent et notent. Si elles sont utilisées dans la recherche de lacunes, elles produisent des lacunes "méta" telles que "déclenché par événement + pas d'IA + haute complexité".
2. Échelles. Catégories nominales avec 3 à 14 valeurs mutuellement exclusives, chacune avec une étiquette lisible, ou des ordinaux courts (0-1, 0-2, 1-3) avec des ancres décrites.
3. Grille écrite : une ligne par valeur avec une définition et un exemple d'élément, plus les règles de décision ci-dessous. Elle va dans l'annexe du rapport et est le seul matériel que le deuxième codeur reçoit à l'étape 2b.
   • Codez la structure logique, pas le rendu. Pour les dimensions spatiales ou structurelles, codez la façon dont l'utilisateur interagit réellement avec l'objet ou raisonne à son sujet, pas son apparence (par exemple, un produit rendu en 3D utilisé sur un plan plat n'est pas "3D").
   • Ordre de priorité pour les valeurs qui se chevauchent. Lorsqu'une échelle nominale décrit quelque chose de perceptuel ou de stylistique (apparence, ton, style), les valeurs se chevauchent. Donnez un ordre de décision explicite ("si A s'applique, codez A ; sinon si B..."), ou fusionnez les valeurs que les codeurs ne peuvent pas distinguer.
   • Ancres mesurables pour les ordinaux. Les ancres telles que la durée, la taille ou l'effort doivent indiquer comment les mesurer et à partir de quelle source (par exemple, "session typique telle que décrite dans la description du magasin ou observée dans une vidéo de démonstration ; pour les éléments basés sur les niveaux, un seul niveau"). Si cela ne peut pas être observé, codez le cas modal et signalez-le.
   • Codez le mode principal. Si un élément est ambigu, codez son mode principal et notez le doute dans une colonne notes.
4. Poids. Par défaut 1,0. Augmentez les dimensions conceptuelles de base (par exemple, verbe à 1,2), diminuez les dimensions périphériques (par exemple, modèle de tarification à 0,4). Justifiez chaque poids.
5. Vérifications structurelles :
   • Aucune catégorie avec moins de 2 éléments ; fusionnez ou supprimez-la (niche_core.py prévient).
   • Tableaux croisés pour détecter les dimensions redondantes (corrélation ≈ 1) : supprimez ou fusionnez l'une d'elles.
6. Reconnaissez les limites : les codes sont des jugements.

Sortie : le CSV éléments × dimensions et config.json avec les échelles, les poids et les règles.

2b. Vérification de recodage en aveugle (obligatoire)

Objectif : mesurer si la grille, et non la mémoire du codeur, détermine les codes. Les lacunes construites sur des dimensions peu fiables sont des artefacts de la grille.

1. Échantillon. Tirez aléatoirement 10 % du corpus, minimum 10 éléments, avec une graine fixe : python recode_check.py sample --items items.csv --config config.json --out recode_sheet.csv --keep link La feuille ne contient que l'identifiant de l'élément et le lien, avec des colonnes de dimensions vides.
2. Deuxième codeur, en aveugle. Une personne différente, ou une session d'agent séparée qui n'a jamais vu les premiers codes (pas d'accès à items.csv, aux clusters ou au rapport), code la feuille en utilisant uniquement la grille écrite et les pages publiques de l'élément. Si le même agent doit le faire, démarrez un nouveau contexte et donnez-lui uniquement la feuille et la grille. Verrouillez le résultat avant de comparer (par exemple, stockez une somme de contrôle).
3. Accord par dimension : python recode_check.py agree --items items.csv --config config.json --recode recode_sheet.csv --out agreement.csv
   • Dimensions catégorielles : kappa de Cohen (κ).
   • Dimensions ordinales : kappa de Cohen pondéré linéairement (κw), qui donne un crédit partiel pour les quasi-correspondances.
   • Le pourcentage brut d'accord est rapporté en parallèle, plus une liste de désaccords par élément.
4. Seuil. Une dimension est réussie avec κ (ou κw) ≥ 0,60 et un accord brut ≥ 80 %. Avec n ≈ 10, le kappa est bruyant : utilisez-le pour trier, et lisez chaque désaccord.
5. En dessous du seuil, dans cet ordre :
   1. Lisez les désaccords et classez-les : ambiguïté de la grille (valeurs qui se chevauchent, ancre non mesurable), confusion entre rendu et structure, ou erreur du codeur.
   2. Corrigez la grille avec l'une des règles de décision de l'étape 2.3 (ordre de priorité, ancre mesurable, fusion des valeurs qui ne peuvent pas être distinguées).
   3. Recodez cette dimension pour l'ensemble du corpus avec la grille révisée, puis relancez la vérification sur un nouvel échantillon de 10 % (nouvelle graine) pour cette dimension.
   4. Si elle échoue encore : réduisez son poids (≤ 0,6), retirez-la de gap_dims, ou supprimez-la. Ne signalez jamais une lacune dont le triplet explicatif repose sur une dimension qui a échoué deux fois.
6. Rapportez le tableau (dimension, n, % d'accord, κ/κw, statut), les modifications de la grille effectuées et le type d'identité du deuxième codeur (humain, agent séparé).

Résultat typique : les dimensions relatives à la fonction (action, objectif, entrée/sortie, déclencheur) s'accordent bien ; les dimensions perceptuelles ou estimées (style, structure spatiale, durée) sont les échecs habituels, c'est pourquoi les règles de décision de l'étape 2.3 existent.

3. Espace : encodage, clusters, gradients et visualisation

Réalisé par niche_core.py. Règle d'or : les clusters et les lacunes sont calculés dans l'espace codé original ; l'UMAP est uniquement pour le dessin.

• Encodage. One-hot × poids/√2 pour les dimensions catégorielles et (x − min)/(max − min) pour les ordinaux, de sorte que changer de catégorie coûte le même prix qu'un déplacement ordinal de bout en bout.
• Clusters. Ward agglomératif avec k choisi par silhouette dans k_range. Un k plus grand n'est accepté que s'il améliore la silhouette de plus de 0,005.
  • Vérification de la plage de k : si le k choisi tombe sur l'un ou l'autre bord de la plage, élargissez la plage et réexécutez ; le script prévient. S'il reste sur le bord, choisissez k par interprétabilité et dites-le.
  • La silhouette entre 0,15 et 0,30 est normale avec des données catégorielles ; ne la vendez pas comme des "clusters nets".
  • Les clusters avec < 3 éléments et les éléments avec des vecteurs identiques sont signalés ; ces derniers suggèrent une grille trop grossière pour distinguer les éléments.
  • Nommez chaque cluster manuellement à partir de cluster_profiles.md et stockez les noms dans cluster_names.
• Gradients. Les loadings de l'ACP (PC1-PC3, pca_loadings.csv) sont lus comme des axes "de A à B".
• Visualisation. UMAP (n_neighbors 10-15, min_dist 0,25, graine fixe) avec un fond de densité KDE. Limites :
  • les distances globales et les tailles des îles ne signifient rien ;
  • transform a tendance à attirer les nouveaux points vers l'île la plus proche, donc la nouveauté d'un candidat est lue à partir de dist_min dans l'espace original, jamais à partir du graphique.
• Cartes de chaleur par paires des dimensions montrent les cellules vides en un coup d'œil.

4. Lacunes

4a. Lacunes combinatoires (triplets). Pour chaque triplet de valeurs des dimensions de lacune (conceptuelles), comparez l'observé avec l'attendu sous indépendance : e = N · p(a) · p(b) · p(c), z = (e − o)/√e. Un triplet est conservé si :

• o ≤ max_observed (par défaut 1) ;
• e ≥ min_expected (par défaut 1,2) ;
• chaque paire du triplet apparaît dans au moins min_pair_support éléments (par défaut 2) : les pièces existent séparément ;
• il touche au moins une dimension d'ancrage (anchor_dims, par exemple le domaine ou le verbe).

Filtre méta-lacune : gardez les dimensions d'attribut hors de gap_dims, et définissez anchor_dims sur les dimensions qui décrivent le contenu du produit. Les triplets composés uniquement d'attributs ne sont pas des niches.

4b. Lacunes de densité. 50 000 à 400 000 vecteurs synthétiques aléatoires sont générés et conservés uniquement si :

1. chaque paire de valeurs existe dans au moins un élément réel (recombinaison de pièces connues) ;
2. aucune règle de cohérence ne les interdit (rules : combinaisons absurdes dans le domaine) ;
3. elles correspondent au profil de l'utilisateur cible (target_filter, par exemple complexité ≤ 1 et libre-service = 1). C'est le filtre d'adéquation utilisateur : sans lui, les lacunes de densité dérivent vers des produits que l'utilisateur ne peut pas construire ou vendre.

Les survivants sont classés par distance à l'élément réel le plus proche et dédoublés sur les principales dimensions conceptuelles (density_dedupe). Comparez avec la distance médiane au plus proche voisin entre des éléments réels distincts (median_nn_distance).

4c. Offre vs demande (optionnel). Par cluster : nombre d'éléments (offre) vs la médiane d'un signal de demande (avis, installations, volume de recherche, étoiles), toujours avec sa couverture (supply_demand_clusters.csv). Un petit cluster avec une forte demande est un indice de lacune (inférence).

4d. Score préliminaire. Nouveauté (1-5, à partir de la distance relative et du triplet qui explique la lacune), faisabilité (1-5, effort MVP avec les ressources de l'utilisateur) et adéquation (1-5, préférences et contraintes de l'étape 0). Pour chaque candidat, vérifiez ses 3 voisins les plus proches en l'ajoutant aux candidates et en réexécutant.

5. Traduction sémantique : du vecteur à l'idée

Choisissez 8 à 12 candidats parmi les triplets de z le plus élevé et les lacunes de densité les plus éloignées ; fusionnez les signaux et supprimez les doublons. Chaque candidat reçoit :

• Nom de travail et un pitch concret de 2 à 3 phrases : ce que l'utilisateur fait, ce que le produit offre.
• Vecteur sur toutes les dimensions ; doit satisfaire aux règles.
• Éléments les plus proches avec distance (× médiane).
• Pourquoi il semble vide dans le corpus : quel triplet ou zone l'explique, et si l'une de ses dimensions a échoué à l'étape 2b.
• Risques : techniques, de marché et d'adéquation.

6. Validation externe et test de mirage

1. Recherche ciblée par candidat, en dehors du corpus :

   • "[concept] + application/outil + tarification" ;
   • "[concept] alternative" ;
   • magasins de domaine avec 2-3 synonymes ;
   • dépôts open source.

   Enregistrez 3 à 5 concurrents avec lien et prix. Supposez que certains apparaîtront presque toujours : un corpus de N ≈ 100 ne couvre pas la longue traîne. Ajustez la nouveauté en conséquence.

2. Test de mirage (adapté de white-space-analysis, voir Références). Le candidat fait face à quatre questions :

   • Taille : y a-t-il suffisamment de personnes ayant ce travail à accomplir ?
   • Volonté de payer ou de changer : de la preuve la plus forte à la plus faible, ils paient déjà pour une solution partielle, maintiennent une solution de contournement coûteuse, ou ont essayé de la construire eux-mêmes.
   • Question de l'acteur en place : pourquoi personne ne l'a-t-il comblé ? Réponses acceptables : conflit de modèle économique ou de canal, un changement externe récent, un segment en croissance. Réponse alarmante : "Je ne trouve pas de raison".
   • Gagnabilité : l'utilisateur cible peut-il surmonter la barrière qui maintient la lacune vide ?

   Verdict : réussi (facteur 1,0), douteux (0,7) ou échoué (0,4).

3. Score final = nouveauté × faisabilité × adéquation × facteur de mirage (plage 0,4-125).

4. Les candidats qui échouent à la validation restent dans le rapport en tant que "fausses lacunes". Ils exposent les biais du corpus et

…

[tronqué pour la traduction]