t4transaction/agent

Application de Valorisation M&A

Ceci est l'application déployée via Docker sur Hugging Face Spaces.

URL Scraper V2 - M&A Headless App

Application M&A headless :

• —Frontend : Next.js + Tailwind + UI custom (style Shadcn)
• —Backend : FastAPI (scraping, matching Supabase, valorisation)
• —Deploiement : Docker (compatible Hugging Face Spaces)

1) Prerequis

• —Node.js 20+
• —Python 3.11+ (ou Docker)
• —Compte Supabase avec :
• —table db_transactions alimentee (embeddings inclus)
• —fonction RPC match_transactions
• —Cles API :
• —Mistral
• —Jina

2) Variables d'environnement

Creer un fichier .env a la racine du projet (ou utiliser les Secrets HF en production).

Variables requises :

SUPABASE_URL=https://your-project.supabase.co
SUPABASE_KEY=sb_secret_xxx
MISTRAL_API_KEY=your_mistral_key
JINA_API_KEY=your_jina_key

Important :

• —SUPABASE_KEY doit etre une secret key (sb_secret_...), pas sb_publishable_....
• —Le backend charge automatiquement .env a la racine.

3) Lancer en local (2 terminaux)

Terminal A - Backend

uvicorn backend.main:app --host 127.0.0.1 --port 7860 --reload

Health check :

• —Ouvrir http://127.0.0.1:7860/api/health

Terminal B - Frontend

cd frontend
npm install
npm run dev

Application :

• —Ouvrir http://localhost:3000

4) Test fonctionnel rapide

1. 1.Aller sur la page Analyse cible
2. 2.Renseigner :
3. 3.URL : https://t4transaction.com/
4. 4.CA / EBITDA
5. 5.Cliquer Lancer l'analyse
6. 6.Verifier :
7. 7.extraction societe (nom, naf, etc.)
8. 8.transactions comparables
9. 9.valorisation
10. 10.points cles

4bis) Workflow de l'application

Cette version headless reprend le parcours metier de l'ancienne app Streamlit, en separant clairement UI (Next.js) et logique (FastAPI).

Parcours utilisateur (frontend)

1. 1.Landing (`/`)
2. 2.L'utilisateur saisit l'URL de la societe et choisit la langue.
3. 3.Redirection vers analyse-cible avec URL/langue en query params.

1. 1.Etape 1 - Analyse cible (`/analyse-cible`)
2. 2.Saisie des donnees financieres : CA, EBITDA/REX, geographie.
3. 3.Appel POST /api/analyze.
4. 4.Affichage d'une progression d'analyse, puis previsualisation des infos cible.
5. 5.Le payload complet est persiste en local (localStorage) pour les etapes suivantes.

1. 1.Etape 2 - Transactions comparables (`/transactions-comparables`)
2. 2.Rechargement du payload local.
3. 3.Appel POST /api/comparables (alias de POST /api/match) avec mots-cles, CA, NAF, geo.
4. 4.Affichage des comparables anonymises + lien vers les references.

1. 1.Etape 3 - Valorisation preliminaire (`/valorisation-preliminaire`)
2. 2.Appel POST /api/valuation avec EBITDA + multiples.
3. 3.Affichage des football fields (CA/EBITDA), mediane/moyenne et caveat.

1. 1.Etape 4 - Points cles (`/points-cles`)
2. 2.Appel GET /api/key-points.
3. 3.3 messages visibles + 2 messages floutes (teaser analyse sur-mesure).

1. 1.Etape 5 - Rendez-vous M&A (`/rendez-vous`)
2. 2.Calendly inline + contexte cible (nom, URL, description, tags, metrics).
3. 3.Objectif: conversion vers un echange expert.

Pipeline backend (etape 1)

POST /api/analyze orchestre les operations suivantes:

1. 1.Validation metier
2. 2.Verifie la coherence des entrees (ex: EBITDA > CA si les deux > 0).

1. 1.Controle de quota
2. 2.Verification minute/jour via Supabase (usage_logs_m_a_transaction_app).

1. 1.Scraping & enrichissement
2. 2.Scraping principal via Jina Reader (avec fallback).
3. 3.Extraction SIREN (mentions legales / homepage).
4. 4.Enrichissement API entreprise (NAF, date de creation, CA eventuel).
5. 5.Blocage explicite si URL/secteur hors perimetre.

1. 1.Matching transactions
2. 2.Embedding des mots-cles cible (Mistral).
3. 3.Retrieval candidats (match_transactions pgvector, fallback Python).
4. 4.Scoring pondere (CA, semantique, NAF) + relaxation progressive.
5. 5.Calcul des multiples mediane/moyenne.

1. 1.Valorisation
2. 2.Valorisation CA (si CA disponible).
3. 3.Valorisation EBITDA (si EBITDA > 0 et multiples disponibles).

1. 1.Journalisation
2. 2.Mise a jour de la consommation tokens / metadonnees meme en cas d'erreur.

Endpoints utilises par le frontend

• —GET /api/health
• —POST /api/analyze
• —POST /api/match
• —POST /api/comparables
• —POST /api/valuation
• —GET /api/key-points

5) Build Docker local

docker build -t leadhook-hf .
docker run --rm -p 7860:7860 leadhook-hf

Puis ouvrir :

• —http://localhost:7860

5bis) Lancer avec Docker Compose (recommande)

Le projet inclut docker-compose.yml pour eviter de retaper build + run.

Demarrage :

docker compose up --build

Arret :

docker compose down

Logs :

docker compose logs -f

Application :

• —http://localhost:7860

6) Deploiement Hugging Face Spaces (Docker)

1. 1.Creer un Space :
2. 2.SDK : Docker
3. 3.Push du repo vers le Space :

git init
git add .
git commit -m "Initial deploy HF"
git remote add origin https://huggingface.co/spaces/<HF_USER>/<SPACE_NAME>
git push -u origin main

1. 1.Dans Settings > Variables and secrets du Space, ajouter :
2. 2.SUPABASE_URL
3. 3.SUPABASE_KEY
4. 4.MISTRAL_API_KEY
5. 5.JINA_API_KEY

1. 1.Verifier :
2. 2.Build logs (image construite)
3. 3.Container logs (uvicorn up sur port 7860)

7) Troubleshooting

• —Erreur quota / policy au demarrage de l'analyse :
• —verifier SUPABASE_KEY (secret key)
• —verifier les policies RLS sur usage_logs_m_a_transaction_app
• —Aucune transaction trouvee :
• —verifier que db_transactions contient bien des donnees
• —verifier que match_transactions retourne des lignes
• —Erreur bind port local :
• —port 7860 deja utilise -> stopper l'ancien process

8) Arborescence principale

• —frontend/ : UI Next.js
• —backend/main.py : routes FastAPI
• —backend/scraper.py : scraping + LLM + enrichissement
• —backend/database.py : Supabase + matching + valorisation + quotas
• —Dockerfile : build frontend + runtime backend