Company Report

Skill : company-report

Objectif

Orchestrer la génération d'un rapport société complet à partir d'un input brut (SIRET, SIREN, URL, ou nom), façonné par un cas d'usage (dd, sales, veille, polyvalent) que l'utilisateur sélectionne avant la recherche.

Input attendu

La slash command /report <input> [--usage=X] transmet :

raw_input: "<ce que l'utilisateur a tapé>"
usage_profile: "<dd | sales | veille | polyvalent ou vide>"

Étape 0 — Capture du cas d'usage

Règle : la skill DOIT connaître le usage_profile avant tout autre travail.

1. Si usage_profile est déjà fourni par la slash command (--usage=X) et appartient à {dd, sales, veille, polyvalent} → l'utiliser directement.

2. Sinon, demander à l'utilisateur via AskUserQuestion :

   Question : « Quel est le cas d'usage de ce rapport ? Cela façonne la profondeur et la priorité des sections. »

   Options :

   • dd — Due diligence / M&A (finances, juridique, écosystème, risques)
   • sales — Prospection commerciale (interlocuteurs, signaux, timing)
   • veille — Veille concurrentielle (positionnement, concurrents, mouvements)
   • polyvalent — Polyvalent (équilibré, 4 angles)

3. Charger Read .claude/skills/company-report/references/usage-profiles.md et extraire pour le profil retenu :

   • sections_prioritaires (ordre de lecture)
   • sections_critiques (confiance bloquante)
   • datapoints_obligatoires_par_agent
   • angles_synthèse

Si l'input raw_input est vide, demander d'abord : « Quel SIRET, URL, ou nom de société dois-je analyser ? » puis poursuivre l'étape 0.

Étape 1 — Détection du type d'input

Appliquer ces règles dans l'ordre :

Étape 2 — Résolution d'identité (séquentielle)

Invoquer le sub-agent company-resolver avec :

raw_input: "<input utilisateur>"
detected_type: "<type détecté>"
usage_profile: "<profil retenu>"

Attendre sa réponse (bloquant).

Branchement selon status :

• status: not_found → écrire un mini-rapport « Société non identifiée » listant les sources essayées, puis arrêter. Ne pas dispatcher les autres agents.
• status: ambiguous → afficher la liste des candidats du champ notes à l'utilisateur, lui demander de préciser via AskUserQuestion, puis arrêter (relancer un /report avec un identifiant précis).
• status: resolved → continuer à l'étape 3. Si confidence: low, prévenir : « ⚠️ Identité résolue avec une confiance faible — le rapport sera produit mais ses sections risquent d'être lacunaires. Continuer ? » Attendre confirmation explicite.

Étape 3 — Dispatch parallèle des 9 sub-agents de recherche

RÈGLE CRITIQUE : invoquer les 9 sub-agents en un seul message contenant 9 appels Agent simultanés. C'est ce qui rend la génération rapide.

Les 9 agents à dispatcher :

1. company-financials
2. company-people
3. company-implantations
4. company-market
5. company-history
6. company-legal (nouveau)
7. company-press (nouveau)
8. company-clients (nouveau)
9. company-ecosystem (nouveau)

Chaque appel passe en prompt le payload du resolver enrichi du profil et de la priorité :

Tu reçois ci-dessous l'identité canonique d'une société résolue, le profil de cas d'usage du rapport, et tes datapoints obligatoires. Produis la section markdown qui te correspond, en respectant strictement le format de sortie défini dans ton agent et en exécutant TOUTES les passes obligatoires pour ce profil.

# Identité canonique (resolver)
<payload YAML du resolver>

# Profil de cas d'usage
usage_profile: <dd|sales|veille|polyvalent>
priority_for_this_agent: <critical|normal|optional>

# Datapoints obligatoires pour ce profil (tu dois les rechercher activement)
extra_datapoints_required:
  - "<datapoint 1>"
  - "<datapoint 2>"
  - ...

# Convention de recoupement
Chaque datapoint chiffré que tu retournes doit être annoté :
- `valeur (recoupé <source1> + <source2>)` si confirmé par ≥2 sources
- `valeur (<source>, source unique)` si une seule source
- `valeur (estimation <source secondaire>)` si déduit d'une source non officielle

Mappage profil → priorité par agent (à appliquer par la skill) :

Datapoints obligatoires : la skill puise dans references/usage-profiles.md la liste correspondante et envoie à chaque agent ceux qui le concernent.

Gestion d'erreur : si un agent retourne une erreur ou un résultat manifestement vide :

• bandeau > ⚠️ Section indisponible — <raison> dans le rapport
• ne pas relancer plus d'une fois
• la confiance globale baisse d'un cran si l'agent était critical

Étape 4 — Détection des divergences (recoupement croisé)

Avant rédaction, la skill compare les datapoints inter-sections et liste les divergences. Tableau de comparaison à construire :

Si divergence(s) détectée(s) → remplir la section 10 (Recoupement & divergences) du rapport. Si aucune → écrire « Aucune divergence majeure détectée entre les sections. »

Conditions d'activation du bandeau d'alerte (haut du rapport) :

• Procédure collective en cours mentionnée par company-legal ou company-financials
• Cessation de paiements datée ≤ 12 mois
• Changement de dirigeant principal ≤ 6 mois (mentionné par company-people ou company-history)
• Divergence majeure entre 2 sections sur un datapoint critique (CA ou effectif > 30 % d'écart)

Étape 5 — Agrégation et rédaction des sections 1, 11, 12, 13

Lire le template : Read .claude/skills/company-report/references/report-template.md.

Synthèse 30 secondes (en-tête)

5 puces concises, calculées à partir du retour des agents :

• Statut (forme + effectif + CA récent)
• Dirigeant principal (issu de people)
• Positionnement (issu de market, une ligne)
• Signal le plus récent (issu de press ou history, daté)
• Confiance globale + nb sections critiques low

Section 1 — Carte d'identité

Remplir depuis le payload du resolver enrichi par les sections 3 (financials), 4 (implantations), 5 (legal), et les annotations de recoupement.

Sections 2 à 9

Insérer directement les markdowns retournés par les 9 agents (pas de modification, pas de paraphrase). Ordre canonique :

• §2 — company-people
• §3 — company-financials
  • §3.1 — company-ecosystem (inséré comme sous-section de §3 pour grouper la lecture finance + groupe)
• §4 — company-implantations
• §5 — company-legal
• §6 — company-market
• §7 — company-clients
• §8 — company-history
• §9 — company-press

Section 10 — Recoupement & divergences détectées

Issue de l'étape 4. Toujours présente, vide si aucune divergence.

Section 11 — Synthèse opérationnelle (ADAPTATIVE)

Lire le profil dans usage-profiles.md et rédiger les angles correspondants :

Profil dd (6 angles) :

1. Lecture financière consolidée
2. Risques juridiques & passifs latents
3. Structure capitalistique & gouvernance
4. Walk-through M&A (valorisation indicative, périmètre cessible, key persons)
5. BATNA repreneur
6. Conditions suspensives recommandées

Profil sales (4 angles) :

1. Interlocuteur cible & circuit de décision
2. Timing & signal d'achat
3. Argumentaire adapté (3 angles pour cette société)
4. Concurrence directe sur le compte

Profil veille (4 angles) :

1. Positionnement déclaré vs. réel
2. Mouvements stratégiques 24 derniers mois
3. Menaces structurelles
4. Opportunités à exploiter

Profil polyvalent (4 angles originaux) :

1. Angle prospection commerciale
2. Angle due diligence / M&A
3. Angle veille concurrentielle
4. Angle sourcing fournisseur

Règle de fond : chaque angle DOIT être étayé par ≥3 datapoints chiffrés tirés des sections amont (citer le numéro de section, e.g. « voir §3 : EBITDA 867 K€ »). Pas de prose creuse.

Section 12 — Sources

Concaténer toutes les URLs citées par les 9 agents + celles du resolver. Dédupliquer par URL exacte. Regrouper par section d'origine. Format : - [titre court](url) — consulté le YYYY-MM-DD.

Section 13 — Lacunes & limites

Trois sous-sections :

13.1 Lacunes bloquantes (pour le profil)

Lacunes qui touchent un datapoint obligatoire du profil retenu. Liste impérative.

13.2 Lacunes par section

Concaténer les « Lacunes identifiées » remontées par chaque agent. Regrouper par section.

13.3 Limites méthodologiques

Bloc fixe rappelant les limites systémiques (pas d'API tierce, RBE restreint, LinkedIn anti-scraping, etc.). Texte standard depuis le template.

Étape 6 — Écriture du fichier

Calculer le slug :

slug = lowercase(canonical_name)
slug = retirer les accents (é→e, à→a, ç→c, etc.)
slug = remplacer tout caractère non [a-z0-9] par "-"
slug = compacter les "-" multiples en un seul
slug = retirer les "-" en début/fin

Chemin final : reports/<YYYY-MM-DD>-<slug>--<usage_profile>.md (date du jour).

Le suffixe --<usage_profile> permet de produire plusieurs rapports différents sur la même société à la même date.

Écrire via Write.

Étape 7 — Résumé utilisateur

Afficher à l'utilisateur un résumé court (5-8 lignes), adapté au profil :

Profil dd :

✓ Rapport généré : reports/<chemin>
  • Société : <canonical_name> (SIREN <siren>) — <forme juridique>
  • Statut juridique : <in bonis / redressement / etc>
  • CA <année> : <chiffre recoupé>
  • Procédures en cours : <nombre> (voir §5)
  • Filiales identifiées : <nombre>
  • Confiance globale : <high|medium|low>
  • Alertes : <bandeaux activés s'il y en a>

Profil sales :

✓ Rapport généré : reports/<chemin>
  • Société : <canonical_name>
  • Interlocuteur cible : <nom> (<rôle>) — <linkedin si trouvé>
  • Signal d'achat le plus récent : <événement daté>
  • Taille de deal indicative : <fourchette>
  • Email pattern : <pattern détecté>
  • Confiance globale : <high|medium|low>

Profil veille :

✓ Rapport généré : reports/<chemin>
  • Société : <canonical_name>
  • Positionnement : <une ligne>
  • Top 3 concurrents : <noms + CA>
  • Mouvement stratégique récent : <événement daté>
  • Awards identifiés : <nombre>
  • Confiance globale : <high|medium|low>

Profil polyvalent :

✓ Rapport généré : reports/<chemin>
  • Société : <canonical_name> (SIREN <siren>)
  • Dirigeant principal : <nom> (<rôle>)
  • CA <année> : <chiffre>
  • Implantations : <nombre magasins>, <nombre entrepôts>
  • Confiance globale : <high|medium|low>
  • Sources : <N> URLs citées

Règles globales

• Pas de recherche directe par la skill. La skill orchestre uniquement : elle invoque les agents, agrège, écrit. Toute recherche est faite par un sub-agent.
• Parallélisme strict en étape 3. Un seul message avec 9 appels Agent simultanés.
• Aucune invention. Si un agent n'a pas trouvé une donnée, la skill ne doit pas la combler.
• Annotation de recoupement obligatoire sur tout chiffre marquant de la carte d'identité et de la synthèse 30 s.
• Détection des divergences en étape 4 : non négociable, c'est ce qui donne au rapport sa robustesse.
• Confiance globale = min(confiance_des_sections_critiques_pour_le_profil). La liste des sections critiques est définie par profil dans usage-profiles.md.
• Bandeau d'alerte : si une condition d'activation est remplie, le bandeau est OBLIGATOIRE en tête de rapport.
• Suffixe de fichier --<profil> : permet de coexister plusieurs versions du rapport sur la même société.