company-scout

Que fait company-scout ?

Prend un nom d'entreprise et crée un rapport d'analyse basé uniquement sur des sources publiques et vérifiables, compréhensible même par un débutant.

Étoile polaire (Critère le plus important)

Le rapport permet-il à un débutant de comprendre l'entreprise ? On doit pouvoir suivre le fil sans connaissances spécialisées : ce que fait l'entreprise → comment elle gagne de l'argent → quel est son marché et ses concurrents → quels problèmes elle rencontre. La cohérence des sources et le format viennent ensuite.

Règle absolue (Directive zéro — Si elle est violée, le rapport est détruit)

1. Utiliser uniquement des sources publiques et vérifiables comme preuves. N'utilisez pas d'informations internes non publiques, d'expériences personnelles non vérifiables, ou de chiffres sans source.
2. Chaque affirmation factuelle doit être accompagnée d'une URL publique, d'un grade de source (A/B/C) et d'une date de vérification.
3. Si une source ne peut être fournie, ne la présentez pas comme un fait. Rétrogradez-la en "preuve insuffisante" ou "hypothèse".
4. Ne mélangez jamais les faits confirmés et les prédictions (hypothèses). Pour les hypothèses, utilisez "possiblement", "estimation".
5. Si vous ne savez pas, dites-le. Marquez les déductions comme "hypothèse".
6. Ne saisissez pas de clés secrètes, jetons ou mots de passe dans les champs de recherche ou les logs.

Grades des sources

• A = Officiel/Standard : site officiel de l'entreprise, offres d'emploi (JD), blog technique, communiqués de presse, réseaux sociaux officiels, DART (rapports d'audit, rapports d'activité), documents gouvernementaux/standards.
• B = Secondaire réputé : articles de médias économiques/technologiques majeurs.
• C = Indice uniquement : communautés, blogs personnels, YouTube, critiques d'App Store, wiki. Ne pas utiliser pour des affirmations factuelles. Utiliser uniquement comme indices d'orientation.

Entrées

• Requis : un nom d'entreprise (ex : "MaRealTrip").
• Optionnel : indice sectoriel, axe d'intérêt (ex : axé finance).

Procédure

1) Déterminer le type d'entreprise → choisir une stratégie de recherche

Le point de départ varie selon le type d'entreprise :

• Commerce/Plateforme (Musinsa, MaRealTrip) : offres d'emploi JD, blog technique, critiques App/Play Store (indice C), articles sur le volume d'échanges et MAU.
• Fintech/Finance (KakaoPay Securities) : DART, dépôts réglementaires (FSS), réglementations et licences, IR de la société mère.
• Comptabilité/Conseil (Samil PwC) : rapports sectoriels, publications, descriptions de poste, tendances réglementaires.
• Non coté/information rare (MediTherapy, Channel Corporation) : compenser par les offres d'emploi JD, communiqués de presse, brevets, interviews du PDG, pages produit. Si rare, avouer honnêtement "preuve insuffisante".

2) Collecte sur 5 axes (Entreprise → Produit → Client → Problème → Entreprises liées)

Pour chaque axe, collecter des sources publiques et enregistrer le grade et la date de vérification.

• Entreprise : structure juridique, historique, taille, modèle d'affaires.
• Produit : principaux produits/fonctionnalités.
• Client : clientèle principale, contexte d'utilisation (B2C/B2B/offre).
• Signaux financiers (si possible) : Rapport d'audit DART (grade A) pour les tendances et ratios du chiffre d'affaires, résultat d'exploitation, résultat net, principaux coûts (frais de vente et d'administration, frais de commission, frais de transport), stocks, flux de trésorerie. Chaque chiffre doit avoir une source et un exercice fiscal. Si indisponible, marquer "preuve insuffisante".
• Problème : problèmes réels rencontrés par l'entreprise/secteur/client. Point de départ : défis mentionnés dans les offres d'emploi JD, défis d'ingénierie dans le blog technique, défis commerciaux dans les actualités/IR, anomalies des signaux financiers (ex : CA↑ mais résultat d'exploitation↓), plaintes récurrentes dans les critiques d'applications (indice C).
• Entreprises liées : investisseurs, société mère/filiales, fusions-acquisitions, partenaires, concurrents, clients/fournisseurs clés. Étiqueter chaque relation avec son type et fournir une source.

3) Vérification de cohérence source-affirmation (léger)

Vérifier que les faits clés (surtout les chiffres) : (a) l'URL est active, et (b) le contenu de la source soutient réellement l'affirmation. En cas de conflit entre sources, mentionner les deux avec "Conflit, re-vérification nécessaire". Rétrograder les liens morts ou incohérences.

4) Organiser les candidats-problèmes + Grille d'aptitude Codex

Au moins 3 candidats-problèmes. Chaque candidat :

• Résumé du problème en une ligne + étiquette [Fait]/[Hypothèse]
• Source publique (grade)
• Score d'aptitude Codex sur 3 axes (Haut/Moyen/Bas pour chaque) :
  1. Disponibilité publique des données d'entrée (API publique, peut-il être remplacé par un dummy ?)
  2. Clarté des limites du problème (suffisamment étroit pour être traité par un seul plugin ?)
  3. Possibilité d'expression sous forme de plugin (peut-il être modélisé par une compétence/script ?)
• Exclusion des problèmes de la finale : les problèmes déjà divulgués (ex : recherche de prix à la Lucky Glide de MaRealTrip) ne doivent pas être repris tels quels ; n'adopter que des variantes adjacentes prouvées par des sources publiques indépendantes.

5) Assembler le rapport (voir le schéma de sortie ci-dessous)

Priorité au débutant : résumé en premier, phrases simples, flux logique.

6) Auto-vérification de validation

Avant de sortir le rapport, vérifier tous les points suivants (si un seul échoue, compléter) :

• Résumé en tête (description de l'entreprise en une ligne + chiffres clés + ce que l'on sait/ne sait pas)
• 100% des affirmations factuelles ont une source publique (sinon rétrogradées en "preuve insuffisante"/"hypothèse")
• Au moins 3 candidats-problèmes, chacun avec source + score d'aptitude sur 3 axes
• Séparation [Fait] et [Hypothèse] + section "Limites de l'analyse" présente
• 3 questions en fin de chaque section
• Tous les termes techniques expliqués dans le glossaire (ou en ligne)
• Références (A/B/C + date de vérification), collection des preuves insuffisantes
• Aucun point bloquant pour un débutant

Schéma de sortie (Rapport)

Les 5 axes principaux sont ceux-ci. Ne pas copier le format ou les chiffres d'un autre rapport.

# <Nom de l'entreprise> — Rapport de compréhension d'entreprise basé sur des sources publiques
Date de rédaction / Date de référence des données / Description en une ligne

## 0. Résumé
- Description en une ligne + aperçu des chiffres clés (source)
- Ce que ce rapport permet de savoir / ne permet pas de savoir

## 1. Entreprise    ## 2. Produit    ## 3. Client
(Chaque fait [n] source)
### Questions (3)

## 4. Signaux financiers   ← Uniquement si A-grade (DART, etc.). Faits uniquement.
### Questions (3)

## 5. Marché/Concurrents / Entreprises liées   ← Étiquette de type de relation + chiffres concurrents
### Questions (3)

## 6. Signaux de problème → Hypothèses sur les enjeux
- [Fait confirmé] ... / [Prédiction=Hypothèse] ...
- Candidat-problème 1..N (problème / source / 3 axes d'aptitude Codex)
### Questions (3)

## 7. Limites de l'analyse
- Ce que les sources publiques permettent de dire / ne permettent pas de dire

## (Optionnel) Ébauche des 5 questions préliminaires
## Références   (Numéro → URL · Grade A/B/C · Date de vérification)
## Glossaire   (Terme technique → Définition en une ligne [+source])
## Collection des preuves insuffisantes

Sauvegarde

Sauvegarder sous out/<Nom de l'entreprise>-dossier-AAAAMMJJ.md (dans un environnement où c'est possible).

Référence

• Un bon exemple de sortie se trouve dans examples/myrealtrip-dossier.md (few-shot). S'en servir comme référence pour le format et la profondeur, mais faire ses propres recherches pour l'entreprise cible.